ActionHero and the ExpressJS Ecosystem

[Clay Himmelberger]

Hey there ActionHeroJS community,

To keep this short, ExpressJS is the gorilla in the room regarding NodeJS web servers. There are lots of packages and plugins that conform to the Express way of doing things. If I were choosing a NodeJS server, using ExpressJS seems like a good idea for support, options, examples, and so on. There are others as well that are similar (Restify, Koa, etc.)

That said, something about AH reminds me of an ESB, which is fitting for the projects my group brainstorms. The documentation for ActionHero is top notch. And this community seems active and has done a lot already (PassportJS, User Authentication and the excellent tutorial, to name a few things).

For those that have used ExpressJS (or similar frameworks) for any project: 

• What has been easier or more straightforward when using AH? 
  
• Anything that is more difficult (or been consistently not-fun)? 
  
• Anything that AH enables that would be a huge pain for Express? (built in web socket support and examples seems huge, when it applies)
  

These are not questions to decide which is "better", just a way to help (outsiders) evaluate. My group is in the process of looking at approaches for some projects and I keep coming back to the concepts of ActionHero.

Thanks, 

Clay

[Clay Himmelberger]

To keep information in the same place, there is a growing plugin system for actionhero inside NPM. More than I expected, and does alleviate some concerns of having to do a lot from scratch (while continuing to show community support)

https://www.npmjs.org/search?q=actionhero

Many useful plugins there.

[Evan Tahler]

I guess it would be cheating if I answered, but the main reason I made actionhero was the mutli-transport features.  Node is singularly positioned to handle "more than just vanilla HTTP(s)", and I was surprised that no other framework made agnostic actions/controllers/etc available to developers.  Using the same logic for both a HTTP POST login and a WS login just make sense to me (DRY, etc).  I actually had HTTP + Socket (tcp) as my initial targets as as I was making games at the time, but the metaphor still applies.  I also think that since node is, by definition an "always on" daemon (unlike PHP or ruby-sometimes), there's also the opportunity to treat other incoming data streams as a "server".   I go over this in detail in the tutorial, but say your app wanted to ingest tweets.  The metaphor can be extended to treat each tweet as a connection and abstractly handle it like an user request, IE: It can chat, trigger actions, etc.  https://github.com/evantahler/actionhero-tutorial/blob/master/servers/twitter.js

I'm also a fan of bundling in background jobs a first-class citizen.  I've never worked on a project where we didn't quickly realize that we needed to separate our "request" threads from our "processing" threads.  Usually email sending was the trigger, but it *always* comes up.  Why not start with it?  Perhaps your project will out-grow the resque-backed job system, but changing the transport of a queue system within a project is easier than implementing one if you haven't used one at all. 

You can of course do both of these things with express with enough add-ons and plugins, but I felt that these features belong as 'first-class' citizens of a modern API server.  

To speak to the negatives, I've seen a lot of folks unhappy that actionhero is not a "rendering" server, meaning that it won't compose dynamic views for you (like rails).  The file server was a later addition to the project (as we had to ensure that file data could also be sent to *all* clients, not just HTTP), and I still view actionhero as only an API server.  I personally feel that a complex asset-pipeline project or rendering engine should be distinct from your backend, and I think that the trend is going this way with more and more front-end frameworks (angular, react, etc) which mostly make your HTML static anyway. 

[rocco...@gmail.com]

in my humble opinion,

What has been easier or more straightforward when using AH?

TOP 1 : code architecture - plugins, actions, tasks
TOP 2 : bundling in background jobs a first-class citizen
TOP 3 : mutli-transport features

Anything that is more difficult (or been consistently not-fun)?

the full-stack app, little further than the tutorial.

Anything that AH enables that would be a huge pain for Express?

there's no such thing, it's like to say it's a huge pain not to be itself and try to be something else.

AH is that pretty collection of hand crated pieces that will seem obvious for those who know what they are looking for and get to know AH for what it is.