How to build microservice applications right? (backend, frontend, database)

Question

I am developing monolithic applications since many years and want to try microservices and containers now.

For learning microservices and containers I am planning a small calendar application (as a web application), where you can create dates and invite others to them. I identified three services that I have to implement:

• Authentication service -> handles login, gives back a JWT
• UserData services -> handles registration, shows user data, handles edits of user data (profile picture, name, short description)
• Calendar service -> for creating, editing and deleting dates, inviting others to dates, viewing dates and so on.

This is the part I feel confident about, but if I did already something wrong, please correct me.

Where I am not sure what to do is how to implement the database and frontend part.

Database

I never used Neo4j or any graphbased database before, but they seem to work well for this use case and I want to learn something new. Maybe my database choice may not be relevant here, but my question is:

Should every microservice have its own database or should they access the same database?
Some data sets are connected, like every date has a creator and multiple participants.

And should the database run in a container or should it be hosted on the server directly? (I want to self-host the database)

For storing profile pictures I decided to use a shared container volume, so multiple instances of a service can access the same files. But I never used containers before, so if you have a better idea, I am open to hear it.

Frontend

Should I build a single (monolithic) frontend application, or is it useful to build some kind of micro frontend, which contains only a navigation and loads other parts like the calendar view or user data view from the above defined services? And if yes, should I pack the UserData frontend and the UserData service into one container?

MVP

I want the whole application to be useable by others, so they can install it on their own servers/cloud. Is it possible to pack the whole application (all services and frontend) into one package and make it installable in kubernetes with a single step, but in a way, that each service still has its own container? In my head this sounds necessary, because the calendar service won’t work without the userdata service, because every date needs a user who creates it.

Additional optional services

Imagine I want to add some additional but optional features like real time chat. What is the best way to check if these features are installed? Should I add a management service which checks which services exist and tells the frontend which navigation links it should show, or should the frontend application ping all possible services to check if they are installed?

I know, these are many questions, but I think they are tied together, because choices on one part can influence others. I am looking forward for your answers.

Answer 1

I'm further along than you but far from "microservice expert". But I'll try my best:

Should every microservice have its own database or should they access the same database?

The rule of thumb is that a microservice should have its own database. This decouples them, making it so that your contract between services is just the API. Furthermore it keeps the logic simpler within a service in that there's less types for data that your service is responsible for handling.

And should the database run in a container or should it be hosted on the server directly?

I'm not a fan of running a database in a container. In general, a database:

• can consume a lot of resources (depending on the query)
• sustains long-lived connections
• is something you vertically scale, rather than horizontally

These qualities reflect a poor case for containerization, imho.

For storing profile pictures I decided to use a shared container volume

Nothing wrong with this, but using cloud storage like Amazon S3 is a popular move here, just so you don't have to manage the state of the volume. i.e. if the volume goes away, do you still want your pictures around?

Should I build a single (monolithic) frontend application?

I would say yes: this is would be the simplest approach. The other big motivation for microservices is to allow separate development teams to work independently. If that's not the case here, I think you should avoid yourself the headache for micro-frontends.

And if yes, should I pack the UserData frontend and the UserData service into one container?

I'm not sure I perfectly understand here. I think it's fine to have the frontend and backend service as part of the same codebase, which can get "deployed" together. How you want to serve the frontend is completely up to you and how it's implemented. Some like to serve it through a CDN to minimize latency, but I've never seen the need.

Is it possible to pack the whole application (all services and frontend) into one package and make it installable in kubernetes with a single step?

This is use-case for Helm charts: A package manager for kubernetes.

Imagine I want to add some additional but optional features like real time chat. What is the best way to check if these features are installed? Should I add a management service which checks which services exist and tells the frontend which navigation links it should show, or should the frontend application ping all possible services to check if they are installed?

There's a thin line between what you're describing and monitoring. If it were me, I'd pick the service that radiates this information and just set some booleans in a config file or something. That's because this state is isn't going to change until reinstall, so there's no need to check it on an interval.

--

Those were my thoughts but, as with all things architecture, there's no universal truth. Some times exceptions are warranted depending on your actual circumstances.