My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
What follows is my personal choice and taste. There are many many awesome stacks that you could choose from. These two are just my favorites.
Approach N°1 - Monolithic App
When writing a single, monolithic app, I tend to decouple the frontend from the backend. This way I can recycle the RESTful backend between multiple clients (web, mobile, native desktop etc).
Web Framework: Spring (Spring Web, Boot, Data, Security etc)
DB: I tend to prefer Postgres for SQL and Mongo for NoSQL. Depends on the type of data
I expose a REST API that the React frontend can call to fetch data and trigger logic.
Approach N°2 - Microservice Architecture
Lately, I really fell in love with microservices, they are flexible and powerful for building complex web apps.
I use the same frontend technologies as the monolithic approach, but instead split the backend logic between multiple independent applications that communicate over RabbitMQ queues.
A REST service (usually I write it in Golang to have fast responses) acts as a proxy between the outside world and the queues, routing requests to the other microservices. I use Kotlin for anything that has computation or complex logic, and NodeJS (with TypeScript) for services that call third-party APIs, for easy JSON manipulation.
I like CockroachDB as DB because it's a fast, scalable and cloud-ready SQL DB that provides all the needed feature for a cloud environment. MongoDB and CouchDB are other popular choices when SQL is not suited.
I think employing a Microservice landscape is overkill for a "one-page one-function" app and only makes sense for more comprehensive applications. For simple ones I'd pick up on a "monolothic" approach. If you're a Java devloper, Spring is probably the backend framework of your choice. You could also take a look at the Spark framework, which is more "lightweight". For the frontend should basically choose between React, Angular and Vue. If you're new to all of them, it doesn't really matter which one to start learning.
Concerning Matteos Approach N°2: What I found somehow interesting reading your post was your suggestions to use a message queue for communication between the Microservices. I didn't hear about that approach, yet (admittedly I'm not too experienced ;-)). Is this a common practice? And why is it better or worse than letting Microservices communicate via REST- or gRPC APIs?
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
Yeah, it's definitely overkill for his scope. Nonetheless, it's a viable solution that can easily grow if the project grows.
About your question, yes using message queues it's actually a fairly old solution when dealing with multiple intercommunicating services. Think about old approaches like Enterprise Service Buses or Java JMS specification.
In a microservice environment, it's actually a really solid solution because it adds a layer of abstraction (the message broker itself) between loosely coupled services and allows for fully asynchronous communications.
Remember, a cloud environment should be error-resilient and services must fail gracefully and not take down the whole application if one of them dies. With message queues if a microservice dies unexpectedly the broker can still receive incoming messages, store them for later (so that the dead service can recover them when it comes back online) and optionally send back a Last Will and Testament message to the other service saying that the receiver has died. Also, Push/Pull, Publish/Subscribe and Topic queue mechanisms give more flexibility and efficiency when designing inter-service communications, and the ability to send binary payloads allow for easy use of formats like Google ProtoBuff or MessagePack instead of JSON, which are much more efficient in terms of bandwidth usage.
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
My name is Matteo and I'm a cloud solution architect and tech enthusiast. In my spare time, I work on open source software as much as I can. I simply enjoy writing software that is actually useful.
What follows is my personal choice and taste. There are many many awesome stacks that you could choose from. These two are just my favorites.
Approach N°1 - Monolithic App
When writing a single, monolithic app, I tend to decouple the frontend from the backend. This way I can recycle the RESTful backend between multiple clients (web, mobile, native desktop etc).
Frontend: ReactJS
Backend:
Approach N°2 - Microservice Architecture
Lately, I really fell in love with microservices, they are flexible and powerful for building complex web apps.
I use the same frontend technologies as the monolithic approach, but instead split the backend logic between multiple independent applications that communicate over RabbitMQ queues.
A REST service (usually I write it in Golang to have fast responses) acts as a proxy between the outside world and the queues, routing requests to the other microservices. I use Kotlin for anything that has computation or complex logic, and NodeJS (with TypeScript) for services that call third-party APIs, for easy JSON manipulation.
I like CockroachDB as DB because it's a fast, scalable and cloud-ready SQL DB that provides all the needed feature for a cloud environment. MongoDB and CouchDB are other popular choices when SQL is not suited.
I think employing a Microservice landscape is overkill for a "one-page one-function" app and only makes sense for more comprehensive applications. For simple ones I'd pick up on a "monolothic" approach. If you're a Java devloper, Spring is probably the backend framework of your choice. You could also take a look at the Spark framework, which is more "lightweight". For the frontend should basically choose between React, Angular and Vue. If you're new to all of them, it doesn't really matter which one to start learning.
Concerning Matteos Approach N°2: What I found somehow interesting reading your post was your suggestions to use a message queue for communication between the Microservices. I didn't hear about that approach, yet (admittedly I'm not too experienced ;-)). Is this a common practice? And why is it better or worse than letting Microservices communicate via REST- or gRPC APIs?
Yeah, it's definitely overkill for his scope. Nonetheless, it's a viable solution that can easily grow if the project grows.
About your question, yes using message queues it's actually a fairly old solution when dealing with multiple intercommunicating services. Think about old approaches like Enterprise Service Buses or Java JMS specification.
In a microservice environment, it's actually a really solid solution because it adds a layer of abstraction (the message broker itself) between loosely coupled services and allows for fully asynchronous communications.
Remember, a cloud environment should be error-resilient and services must fail gracefully and not take down the whole application if one of them dies. With message queues if a microservice dies unexpectedly the broker can still receive incoming messages, store them for later (so that the dead service can recover them when it comes back online) and optionally send back a Last Will and Testament message to the other service saying that the receiver has died. Also, Push/Pull, Publish/Subscribe and Topic queue mechanisms give more flexibility and efficiency when designing inter-service communications, and the ability to send binary payloads allow for easy use of formats like Google ProtoBuff or MessagePack instead of JSON, which are much more efficient in terms of bandwidth usage.
Very interesting thoughts, thank you ;-)
You gave me the idea to write a dedicated post about my experience with queues and RabbitMQ. Could be interesting, thanks to you :D
Please do it and let me know when it's finished!
Would love to hear about it too.
After a lot of time, I finally published it :D Please share your thoughts, I'd love to know what do you think.
dev.to/matteojoliveau/microservice...