This is part 2 of the series about scaleable architecture for SPAs. Part 1 discussed the benefits of SPAs. But what if you are building a multi-product solution with a large development team? This post will compare a single-SPA architecture with a multiple-SPA approach.

Multiple SPAs

The main attraction of the multiple-SPA approach is one of organizational simplicity. If you have a large integrated solution, you probably already have teams for each product or functional component that you deliver. Each team can deliver its own SPA independently of the other teams. Each team can schedule its own release dates without the need to coordinate. Additionally, separating the functionality into separate SPAs keeps each application more lightweight and focused. There’s less of a chance of developers stepping on each others’ toes. Since the positives of this approach revolve around separation, the negatives predictably revolve around coordination and duplication.

First, if the solution is to feel to the user like a single integrated whole, then UX must be closely coordinated. Changes to styles or UX components must be quickly disseminated across the whole solution. If you are coordinating UX by consuming a style guide or component library, each team must be encouraged to keep up-to-date. Failure to do so will result in a solution that looks patched-together.

Secondly, duplication can become a problem. Unless the teams develop a shared library of code for common functions like error handling or authentication routines, you will end up spending a lot of time writing the same functionality in slightly different ways. This becomes an invisible tax on productivity. If you do develop a shared library (and you really should), it becomes another dependency that must be kept up-to-date.

Single SPA

I’m not going to write out three paragraphs that are the opposite of the ones above, so it must suffice to say that most of the strengths and weaknesses are the opposite of those that we just explored for a multi-SPA solution. However, the main attraction for me of a single-SPA approach is the cohesiveness that can be achieved when there is a single application and all functional components or products can share a common core of UX and other functional code.

What hasn’t been said yet is that some of the negatives associated with a single SPA can be alleviated through good architecture that allows multiple teams to build and deploy multiple products within a single SPA structure. That will be the focus of the next installment in the series.