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:
Let’s consider each one of these factors individually.
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.
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!”.