This is a cross post from a Quora question that I answered. I figured I'd give it some love on my blog since I wound up putting a lot more thought into it than intended.

Services based nowadays.

a) and API server built on either ExpressJS + package soup or Loopback

b) a Web Server with any modern front end SPA style framework of your choice. My current preference is React. I’ve done a ton in everything except Vue.

c) other services as their own separate “apps” with an API to interact with the others

d) token based authentication between all of them

Why:

a) If your app grows for the need of additional clients (mobile, third party integrations, a brand new front end), your API is ready to go.

b) Separation of concerns. An optimal front end development environment will not always merge well with an optimal back end development environment.

c) Scaling. Need more services? Great add some more, create the API or use something like AWS SQS to decouple everything.

Why not:

a) If you’re just making a small app, or proof of concept, sure nothing wrong with rolling with an all-in-one framework

b) The time to learn all required things > then time available to meet deadlines or accomplish goals

c) You have no choice

Specifics:

a) I spent about 2 years in Meteor land, and it becomes an uphill battle very fast. In fact, you have an exodus of some of the big players like Kadira and their team, which is one of the only ways to actually monitor Meteor apps. Maybe things have changed, but their big selling point on real time becomes kind of null when we ask ourselves, “How often do we really need socket data sync?”

b) Sails. Or is it trails? I’m not sure. I know one has stagnated and the other is apparently community driven. Either way, it’s an attempt at MVC, keeps everything together in one big package. Maybe it’s good, and I’m sure there’s parts about it that are fabulous, but I like keeping separation of concerns.

c) Express. Obviously a popular choice and obviously great. Although I’d argue it’s due the lack of options? Or maybe that it does so little in reality. Does anyone actually enjoy package hell? Meaning having to play easter egg hunt with every single package? Maintain them? Dedupe dependencies constantly? (unless you’re using yarn). I mean don’t get me wrong, it is and should be a huge go-to, but it’s so low level you’ll wind up repeating yourself a ton.

d) Loopback. I discovered this this past year and have been loving it. It takes away a lot of the redundancy of setting up APIs, authorizing and authenticating them, setting up model relations, hooking up models to different data sources… Only draw back is that the documentation is miserable. And I mean quite bad. I still like it, but they don’t even have all of their functions and aliases documented.

I actually have a guide of loopback you can view here:

Authorized Resources and Database Migrations with Strongloop's Loopback

e) Just use React. It’s great, fast, well documented, huge community, and you can use as much of it as you’d like or as little. You can use it for just the view, you go full redux/flux and routing and all the bells and whistles and do everything. Oh, also all the big players use it. Facebook actually uses it in their own core app which is a HUGE battle test that most frameworks can’t even slightly boast (angular is used in PS4 youtube app…… woohoo).

The only thing I think I forgot to add was... well it makes it sounds as if I don't like any of them. That's not true, I think they all have their place. However, I think the full JS oriented stacks operate based when split into smaller services. Of course Docker and friends are great for this, so that you can have one piece of hardware and utilize it's resources to max.