Application Development Stack
This is an exciting times for application development where we see new challenges and tools/technologies/design patterns available to solve these challenges. The challenges are architecting for scale and cloud, better control through automation, fast feedback loops and faster rate of development.
Choices made at the start of any application development go a long way in determining project success on all possible scales. These choices can be at the architecture level, tools/languages/technologies level, deployment strategy level etc.
This post is my opinion at the technology level against different development criteria -
Speed of initial development(prototyping) - When ask is to quickly get to a prototype,I prefer MEAN(MongoDB, Express, Angular, NodeJS) stack. In agile world we live in, this is a great enabler as it provides lots of choices when it comes to quickly developing a modern application. Add some good UI library(bootstrap, AngularUI etc) and you have an application that does not look like an amateur/under-development prototype. We all know that irrespective of intent or elegance of back-end code, it is the UI which can be deal maker(or breaker). UI (more appropriately UX - User eXperience) also mean how usable the product is and these JS and CSS libraries already contain most of the UI usage pattern implementations.
Service Layer considerations - Having won the prototyping battle, you may need to change some of the technology decisions taken in above step, which is only natural as you move from a prototype to actual product development. While I would stick with UI choices made i.e. Angular (and optionally Express -web server), we can certainly move on to some other technologies for service layer ecosystem and database. This means replacing NodeJS with a more mature platform e.g. JVM platform. The non-blocking concurrency benefits provided by NodeJS can also be achieved on JVM using 'Akka actors' (my impression between Akka actors and 'nactor' -a NodeJS actor implementation - is that Akka actors is more elegant and propagate a message driven and reactive design considerations).But more importantly, Java(or Scala) seems a better choice as languages (compared to JavaScript) when it comes to modularizing your code, using good old OOPS principles, type-safety of these languages, tools/IDEs available etc.
Service Composition - Having different technology stack in UI and service layers helps us visualize UI layer as just one of the many consumers of service layer. Service layer exposed as APIs(REST or not) can be consumed by UI, and/or for integration by other applications, and/or even exposed for client developers to create solutions on top of service layer capabilities. This leads to a design where service layer is totally free from ever changing customization needs of UI layer and service composition logic( rendering a page using aggregation of responses from different service APIs) sits inside client side JS controllers.Again, this is not a new concept.
Testing and automation - No testing framework can force you to write quality test code, it is ultimately a developer task to decide what and how to test to have best control. With JS libraries being developed recently there is more support for BDD. But Statically typed languages(Java, and scala) add an extra layer of validation (checking type of objects at compile time itself) and that can be an invisible test present from language itself. At the same time, NodeJS being all JavaScript, would be faster to test code changes as there are no compilation cycles involved. Not sure about maturity of reporting tools integration with automation services(e.g. Jenkins) though for NodeJS.
Deployment architecture support - While all technologies can be deployed on cloud(onus lying on application development/deployment team), NodeJS has native support from cloud providers(AWS Lambda has NodeJS programming model documented along with Java,C#,Python. Microsoft Azure provides OOTB NodeJS software). AWS Lambda allows you to fix your pricing model on number of lambda requests executed, providing a low level cost control.
Ability to simulate cluster for integration testing - The goals is to make development/staging environment as close as possible to the expected production environment so as to avoid surprises in actual journey. This means either you manually cluster configure your automation boxes or you put cluster configuration inside code. One of the reasons of popularity of Containers(Docker etc) is the ability to codify configuration , and we should strive for later option. Also, generally you have different set of people(and skillets) maintaining/configuring web servers and application code. Ability to launch cluster from within application is where Akka cluster impresses me. Same in NodeJS can be achieved easily using custom scripts as launching web servers(Express) is a trivial task.
Skill-set considerations - MEAN stack promises single programming language, JavaScript, across all layers. The term 'Full Stack Developer' comes from this ecosystem, although I believe in specialization with front end vs back-end being a reasonable boundary which ensures that these two parts stay de-coupled, especially back-end should not know too much about front-end(i.e. enforcing step 'Service Composition') and different 'type' of developers works in the two parts. By presentation layer and service layer not sharing technology stack, it helps to deploy each as separate unit of deployment. We have lightweight deployments now where one layer can be upgraded without re-deploying entire application.
This is an opinionated article on what I see as a balanced technology stack based on my own experience. I would like to see other opinions(feel free to respond where you differ) as my opinion is limited to my own experience and knowledge.