Lightweight, configurable static web container
In this post I’ll cover the approach I’ve used to make an easily deployable, configurable front end for a single page app (SPA) in a quasi-microservices deployment. It represents the extract the UI step as outlined in Christian Posta’s post. Monolith to Micro-services I use the following spectrum of monolith to micro-services: Stage Description Advantages Constraints Fully monolithic The UI and backend services are packaged and deployed together, and the UI is rendered server-side. Easy to coordinate deployments Hard to work on in parallel Bundled SPA The UI is an SPA, and talks to the backend by an API, but is packaged with the backend during the build process UX improvements due to application like interactions Duplicated code to validate at the frontend and backend. More complex interactions between the frontend and backend Packaged SPA Same as Bundled SPA, except the frontend produces its own build artifact that is included in the application (think webjar, or NPM package) UI developers do not need to know how to build the backend server. Able to have a dev API server As per Bundled SPA Independent Frontend The UI is packaged and deployed separately to the backend Easily have different release cadences for the frontend and backend. Able to have multiple different frontends for different customers, tests, etc More coordination needed between the frontend and backend deployment (e.g., API versions, connection holding, etc) There is no right position on this spectrum. It is highly dependent on the business requirements (development cadence), existing technologies, staff capabilities, etc. ...