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.
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...