Although you might (should) want to start your application as a monolith first, I would like to suggest that you should decouple your back-end from the front-end from the start.

What do I mean by that? It simply means front-end and back-end as separate stacks (some call it split stack development). Normally this means a JavaScript Single Page App (SPA) front-end and a back-end that acts as an API.

A split front-end and back-end stacks is a good middle ground between a monolith and microservices. The main benefit of this approach is flexibility of changing either of the stacks when the need arises.

There are costs of maintaining separate stacks, I’ll highlight them below. But after working in few projects that uses “one stack/framework to rule them all”, the benefits outweigh the costs in my opinion.

The flexibility problem

One of the projects that I am involved with is written with Grails. As a typical MVC framework, Grails is responsible for both back-end and front-end.

A requirement came from the client to implement multi-tenancy. Sounds like a reasonable request, but the team faced one roadblock after another. Yes, we are aware of Grails multi-tenancy guide, but we couldn’t get that to work with our application.

Honestly, this is one of the many frustrating things that we found working with Grails. The team came into conclusion that re-writing the application in another framework / language would be better for the future. A more popular framework like Ruby on Rails that is suited for rapid application development with a strong open-source community sounds like a good fit for us (I admit I am biased).

However we couldn’t easily move forward with the re-write as the effort to re-write the software would be simply too much for us to tackle at this point. Were the software was implemented using the split stack approach, we could stagger the re-write. Assuming we are happy with our front-end stack and Grails as the back-end is the thing that we want to replace - we could gradually swap the APIs with a different backend framework.

I never realised the benefit of having that flexibility until now.

The costs

Image from here, original image from Dinosaur Comics

As with most things in software, choosing one approach over the other is about trade-offs.

The future-proofing afforded by the flexibility comes with costs, here are some of them:

• Additional burden of maintaining two ecosystems. Both ecosystems have their own package management, version manager, testing framework, servers (the SPA needs a simple rendering server too - separate to the API server), deployment methods, build pipelines .. I should stop now.
• A JavaScript SPA is more complex compared to server rendered pages sprinkled with jQuery.

To put it simply, the cost of flexibility is the increase in complexity.

The split stack will especially make sense if there is a front-end / JavaScript specialist and a back-end specialist in the team. A generalist with experience in both stacks will work too, in retrospect, that’s how I have helped a startup before - setting up split stack from scratch.

Summary

Architect your software for flexiblity from the start makes sense, I feel the flexibility offered is just too hard to ignore, but be prepared to handle the increase in complexity.