Should I keep UI and backend separate or combine considering cost to run

Question

I am developing my first SaaS application that will be hosted in the Google Cloud or any other similar cloud. To give an idea about the nature of the project: it is a somewhat simple SaaS, multi tenant based, where a client creates an account and gets a system to use. Initially, compute is low, no major data processing. Clients can save reminders, create certain hierarchical lists, manage certain aspects of their internal data etc. This service will start with a free tier, very limited (or a trial) and then eventually I will launch a paid subscription tier. Long way to figure out all these details. Nevertheless, I do need to keep this design as cost effective as possible within a very reasonable performance. I don’t have any concrete usage estimates but will probably start with 50-100 clients and potentially grow into tens of thousands.

So initially, I will have two components: Web UI (React) and REST backend (Spring + MySQL). I can design this in two different ways:

A. As separate micro services: -Spring based REST API backend + MySQL (two containers) - Nodejs Express + React Web UI front-end (separate service) - Total of three containers running

or

B. Spring REST API backend + React Web UI front-end in one service + MySQL - Total of two containers running

My thoughts... From design and scaling perspectives, I personally prefer A. With this case I get clear separation of services and a truly micro service oriented architecture. I can scale each service accordingly. The downside is a bit of complexity, a bit of response time degradation and potentially a higher cost to run.

With B I obviously get a simpler system, most likely less maintenance and a lower cost.

What I am looking for is for some thoughts on this from the experienced folks. What should I consider most important and which would seem like the better option for the above scenario?

Answer 1

Quoting Michael Washburn Jr's article:

1. Modularity One benefit of splitting your app up into a separate backend and frontend app is modularity. With your application logic completely separated from your user interface, you have a slightly more modular web application. Modularity aids in a number of things, including testing, readability, and maintainability.

2. Reusability With a separate API, your application logic can be reused by any number of applications. This means you can make a mobile application that utilizes your API, consume your API in a completely separate application, or even allow others to access your API (for free or for a price).

3. Content Delivery With your client-side application a completely separate entity, you can take care of advanced static file serving techniques that are otherwise unavailable to you in applications where the UI needs to be rendered server-side. For example, you can now use NGINX and some simple rules to cache your entire client-side application.

4. Responsiveness One of the greatest pitfalls with an “all-in-one” server-side application is giving users responsive feedback. A typical workflow for a user clicking a button to fetch data looks like this in a server-side application:

A user clicks a button to fetch data The browser sends a request to the server The server queries the database The application performs logic on the data The application renders data in a view The server returns the response to the user The user sees feedback after waiting the whole time for the page to load. With a separate client-side application, you can take advantage of a number of feedback mechanisms such as using loading spinners or progress bars. Once your request comes back (via an AJAX call, for example), you can update your view.

Edit 1

5. Versioning Yes, I added a #5. With separate API and UI projects, you can upgrade and deploy one without the other. If there’s a critical issue in your new UI deploy, you can roll it back without sacrificing the performance improvements you just made in the API project.

Edit 2

What Are The Advantages of a Monolithic Architecture? This split architecture has many excellent benefits. However, there are some benefits to using a Monolithic Architecture as well. For instance, if your application is contained to a single project, you can develop it much faster. It’s no secret that more coding is involved to make a separate user interface and API (but many frameworks are making this easier). There are also security benefits that you get out of the box. For instance, the fact the you’re not exposing an API at all. There are ways to protect your API, but not having to is even better. If you have more advantages you’d like to talk about leave a comment and let’s talk about it.

ref: https://michaelwashburnjr.com/blog/4-reasons-web-app-separated-frontend-backend

Answer 2

From my experience I prefer A in the long term for scalability and so your backend developers don't have to deal with frontend issues. Every system I've worked on that didn't have that clean separation between the UI and backend ended up being a deployment and build nightmare.

I would prototype with B while trying to keep the UI and backend as separate as possible so that you could switch to A once you have enough of a revenue stream to support it.