The PHAN Stack
And why you should try it.
The MEAN stack is great. It’s a stable, cookie-cutter solution to jump-start any project. I’ve used it in many projects over the years, on small and medium size teams, and at hackathons. However, I recently consulted for a company that was rebuilding their stack and the requirements came out to include PostgreSQL for the data layer and hapi as the node framework of choice. I jumped headfirst into the hapi ecosystem and was very satisfied with what I discovered.
Read on for the components of my new go-to stack and the rationale behind them:
PostgreSQL (vs Mongo): NoSQL is great, but it’s always made me worry when building applications with data that was inherently relational. Originally coming from the SQL world, I easily fell in love with the unstructured nature of Mongo, and it’s rich query language, text indexing, and aggregation framework. As applications grow however, you start worrying less about convenience, and more about reliability, consistency and performance. Search moves off to ElasticSearch, caches/CDNs handle frequently accessed data, large jobs move to off to Hadoop/Spark, and the only thing you really want your primary database to do is to stay up and keep your data model safe.
Working on a marketplace application with millions of content rows, using PostgreSQL was the right architectural decision. Working with JSON via the JSONB type where needed, we meticulously approached our data model design, and made sure that we made good long term decisions. You can protest and say that one can carefully approach modeling data in Mongo, which is true, but not practiced in most teams (especially those starting out with a MEAN stack boilerplate), as the tools and community are still young, and few large scale production deployments have been studied in depth. Model relationships and out-of-the-box schema validation are only a few months old and will no doubt change and improve as they get battle tested.
How to switch: Instead of raw Mongo queries or Mongoose, try Knex.js, Bookshelf.js, Sequelize to manage your data model and run queries.
If your first database was (and is) Mongo, please at least read a book about databases. Oh wait, if books are not your generation’s thing… then at least this.
Hapi (vs Express): Express is simple, extendable, stable and popular. Why do I need a new framework? There’s only one way to find out, but you should know that hapi is being used at tons of companies you know and respect, and is endorsed by a team of node experts who are also an authority on node security (via ^lift security). Disclaimer — I personally worked with them through a security audit — I recommend. ;)
But forget all that for a second. I switched to hapi because it promotes thinking about APIs as first-class citizens — writing the API contract, documentation, input/output validation and tests. Hapi’s design and structure make this effortless, while still being easy to understand. The benefits from this are felt toward the middle and end of the product life-cycle, with safer change management, easier maintenance, and better stability in production. If you have a service oriented architecture with lots of APIs, as we did, you can probably imagine the compounding positive effect we got from investing into well structured APIs.
How to switch: Start your next application with hapi.js. There is an excellent community and a healthy plug-in ecosystem, with solutions for common tasks like authentication, documentation, CSRF, sessions, testing, and templating.
Check out this minimal boilerplate I created as an example of a hapi API with a focus on testing, documentation and CI.
Angular: Changing the A in MEAN would mess up the phonetic quality of the whole acronym so I will leave it alone. In reality though, Angular is still my go-to framework for building front-ends quickly. React and Flux are great, but when it comes down to working on a team of engineers with varying skill-levels, I feel that Angular provides a more structured platform to build and maintain larger applications. This feeling comes from overseeing two teams shipping software with both frameworks over the past year. Angular 2 is in beta and bringing lots of features and much needed performance improvements, so that’s what I’m looking forward to.
Node: Its simple, fast, and fun to work with. The community and tooling are outstanding, and I think it will be around for as long as JavaScript is still used on the front end. The few reasons I can come up with to look past Node (and to languages like Go or Elixir) for your web layer is if static typing is a must for your use case, or if your margins rely on squeezing performance out of web servers.
So… stop being MEAN, try it out, and become a PHAN!
