My Thoughts on Single Page Applications
When deciding on the architecture for a new web application there are many different options, ranging from traditional server-side driven sites that utilise templating engines, through to hybrid solutions that are fully server-side applications but include quite rich JavaScript components, as well as full-blown SPAs talking to a REST API back-end. Each option has its own pros and cons, but I think many software engineers are too quick to assume that an SPA with a REST API back-end is the most appropriate architecture (or, indeed, the only architecture) for a new web application.
In making the decision about which architecture is the best fit for a new application, I think it’s important to consider the following factors:
- Does the problem domain demand a high level of user interactivity, such as video or image management, rich editors, games, etc?
- Can you get away with a service such as Firebase that enables you to avoid building a back-end altogether?
- Is the product and the team likely to grow so large within the next 2-3 years that physically separating the front-end from the back-end will be essential to managing the complexity?
Let’s consider each one of these factors individually.
If you’re building a product that will have a very rich and dynamic front-end then an SPA written in a modern, component-based JavaScript framework may well be the best solution. But don’t underestimate what is possible with a hybrid solution that is back-end driven and still includes some rich front-end components. You can achieve a lot with a hybrid solution and it will be much cheaper to build and maintain (more on that below).
Another possibility is that you’re building a product that doesn’t have much in the way of reporting requirements or other back-end functionality, in which case you can possibly get away with something like Firebase, which means you can build your entire product as an SPA.
And finally, there is the issue of scale and the benefits of physical separation that a full SPA provides when the product becomes super-complicated and the team becomes extraordinarily large. Indeed, this was the case at Facebook when React was developed and this is one of the scenarios where having a completely separate front-end and back-end makes sense. However, I honestly believe that far too many developers jumped on the React bandwagon when it was released (and, by virtue of that, the SPA bandwagon) without really understanding what problems SPAs were solving nor the additional costs that would be incurred by adopting this architecture. Developers just saw React, Angular and other client-side JS frameworks becoming a popular way to build a modern web application, without considering if it was the best way to build their modern web application.
If you’re building a new product your emphasis should be on shipping fast and getting customer feedback as quickly as possible, not worrying about some day in the far off future where you might have a product that is so huge and complicated that it might need to be split up into separate pieces. If you can’t ship fast and find product-market fit in the early days, there is zero chance you’ll face that problem, so why burden yourself with the cost of solving that problem in the beginning? Before answering, keep in mind that Instagram sold for a billion dollars with only 13 employees and WhatsApp sold for several billion dollars with only 20 employees. I have no idea what their tech stacks looked like at the time, but whatever they chose I’m sure it wasn’t done so that work could be split up amongst hundreds of engineers, as they didn’t have hundreds of engineers.
I’ve mentioned the costs of maintaining a two-tier architecture several times, but what are they? Assuming the new application uses a Node back-end then at least you only have to hire JavaScript developers, so that’s a win. However, you may end up with two teams anyway, with front-end changes only being reviewed by front-end devs and back-end changes only being reviewed by back-end devs, which is already less efficient than a team where everyone can (and does) review everyone else’s work. And, of course, if you’re using a language other than JavaScript on the back-end then you’ve just added the complication and cost of needing to maintain two skill sets in your development team and now you’ve virtually guaranteed that front-end work is going to get blocked by back-end work and vice versa, which will definitely slow down development.
Additionally, regardless of back-end language choice, you will inevitably end up with two code bases with two sets of dependencies to manage, two test suites, two build pipelines, etc etc etc. Hosting infrastructure will be more complicated to monitor and maintain and you’ll need to manage the production deployment and rollback process for two separate artefacts.
Whilst the additional cost that each of these factors adds may not seem too high when considered in isolation, when you add them all up the total cost will be quite significant and this cost will be paid in terms of project velocity and/or the need for additional resources.
Contrast the two-tier approach with a traditional server-side rendered application or a hybrid application. In both cases the objective would be to have one code base, with one set of dependencies to manage, one test suite, one deployment pipeline, etc. The developers hired to work on this type of application will essentially be full stack developers and each developer will be able to work on any part of the code base and review any other developer’s work. Accountability is enhanced because front-end can’t blame back-end (or vice versa) and features can be managed through the development process as atomic units rather than separate pieces of work, which often requires more effort to co-ordinate the timing of the deliverables.
Finally, I have heard the argument that building an SPA will force your company to build a REST API, which can then be used when the company builds its mobile application. This is very optimistic thinking and it probably won’t work out the way you intend, because if the API is built for the SPA before the mobile app development starts then you will inevitably get it wrong and need to go back and modify it anyway. At that point you’ll either need to change existing endpoints, which may necessitate changes to the SPA, or you’ll end up creating new endpoints, thereby debunking the idea that you can build an SPA and get a mobile-friendly REST API out of it for no extra work.
You would think, having written an article such as this, that I am completely against SPAs. Actually, I am not. What I am against is people making software architecture decisions based on hype and fashion trends rather than critically analysing the available options and realising there may be a less fashionable solution that actually makes far more sense for their situation.
That’s all for now. Check back in another five years for my next article, entitled, “The Rise and Fall of AI - Where It All Went Wrong!”.
