Your controller are responsible to just delegating the responsibility to someone. When you've some complex business rules, are recommended you have another abstraction for you business rules and this complexity the in that layer. But, in general, depending on your app specific, there ok to prototype the rules inside controller to not introduce an unnecessary complexity on the stage 0 of the app, but when it grows are good to create the business layer and do the right responsibility in the right layer.

The benefits are the same of many others languages, and as Pankaj Patel says, the most benefits are for Swift developers. Swift are a pretty good language for developing any types of applications, but right now is not mature like Go, Node.js, Elixir or even Ruby. When you're developing a server-side application for production, you need trust and stability from your language and dependencies, of course innovation are very welcomed, but its a big deal when you're on business, startups have more flexibility to change in this point. But, well, talking about performance. Benchmarks over web in many times are not a good comparative to choose a language, because benchmarks focus on minimal cases, not productions cases, there's no integrations or business rules applied, its just rendering a json or something like this. See the article from Eran Hammer about it. When you're using a language built around a compiled language of course compiled languages have more performance than a interpreted language. Swift have a really nice opportunity to grow and be a awesome backend tool, but right now IMHO are not ready.

Well, if you really get 16MB at your document in MongoDB, probably something goes wrong. When you modeling your document(model) for MongoDB, you have some features to prevent store much more redundant information thats necessary. I follow the rule: If you've a subdocument set that you don't have control over it, like comments in a post, is much better just have an array of references for another collection. But if you have control over your subdocument, like metadata, you can just use this subdocument direct on your document not using a reference. But, if follow this rule and you still get 16MB at your document, well, try thinking about a SQL like database and normalize your data.

When we need fast development and an simple and elegant way to create micro services, Node.js os a good option. Node.js not solve all The problems, but you can integrate and manage all your services just using Node.js. Go also a good option too lime perhaps Elixir or Rust too. If you're not confident with Node.js just because Callback Hells, you really need go dive in JavaScript and learn a Little more than the basics to avoid callback hells.

Awesome post! I just have some tips to adding. When you really close your network with database + app adding an extra layer of protection with password are maybe redundant. You database is only access by your private network, no internet connections are available (particularity, I prefer accessing the database instance just by accessing other secure instance and then accessing that). I'm not entire sure about the 3.0 version of mongodb, but the previous versions, the authentication mechanism is ver simple and not much efficient.