Microservices are the 'in' way of developing software at the moment, and have been for quite a while now. They certainly seem to be past the 'oooo ...
For further actions, you may consider blocking this person and/or reporting abuse
Thanks for the article James. Good points noted here.
I do have one concern, which I think the example you have provided may just be slightly leading down the wrong path. Ideally, a microservice from my understanding should be able to work independently. By having direct service calls within the methods, the initial goal of decoupling is not quite achieved. We are still coupling the service and a break down of product service will still cause order service to fail.
What would be your suggested approach and communication methods to tackle that problem?
My though process would be that we could continue to use the methods you have provided here, but at an async level (perhaps worker svc) which will capture the relavent data and store in the order microservice. There can then be a standard in process call to the data store in the order service. Any thoughts on that or suggestions?
Thanks.
Srini, unfortunately, a completely isolated microservice that works independently is a myth. Services have to communicate with each other using any available mechanism.
Think about this: get the code of your monolith and refactor in such a way where its components don't interact with each other. It is simply not possible and does not make sense. Then instead of having in-memory method calls, adding a network layer and process isolation comprise microservices.
Hey Srini, thanks for the comment!
I completely agree on the coupling point, and that they should be able to work independently. That's one of the main reasons I always gravitate towards an event-based communication model.
All of the best message brokers support some level of state, so if the order service publishes an event and the product service is offline the event will just wait. Once the product service is back online then the event will be processed.
I think the point gRPC is trying to make with HTTPS only, is that there's very few scenarios where using HTTP make sense for any web-based API. This includes APIs that aren't publicly accessible.
letsencrypt.org greases the wheels for deployments, with very little overhead.
Hey Matthew, thanks for the reply.
I have always known about let's encrypt, but hadn't put two and two together in my head. You may have just changed my preferred interservice communication option :-)
Sweet! Ping me if you run into any issues. I've used it for Windows Servers a handful of times.
Amazing, will do. Thanks Matthew :)
James, you made me happy by sharing experience and mentioning inter-service communication :D I'm just glad to see other people having similar problems that I've had in the past.
It is funny that you gave a code example in the very beginning which does not work in a microservice world. Let me prove you wrong! (in a good sense) I've been building new microservice programming concepts where you can choose a communication mechanism without writing any code!
I wonder if this microservice project can also help with your needs.
Hey Serge, thanks for the comment. It's interesting your view that the example (albeit a very trivial example) doesn't work in a microservice world. Could you elaborate why?
DaSync looks an interesting project. I started working with Dapr last night which seems a very similar piece of work.
Of course! Let's say
IProductServiceis HTTP or gRPC client. The code would work. However, now you need to handle errors if aValidateProductscall fails on the network level. Then at some point, you need to replace simple request-response with a message queue to create a more robust workflow. In that case, you have to refactor the code of your services to accommodate message handlers - it is not a simple method call anymore.D-ASYNC gives you a language-integrated way to describe inter-service communication regardless is they use a synchronous or asynchronous channels. So in that particular example, you can use a message queue when calling
IProductService.ValidateProductswithout re-writing the method. That will ensure the statefulness of the method execution (a state of a workflow).And yes, dapr! In the middle of the spectrum you have dapr - a K8s sidecar that facilitates communication and state management, but does not reduce the churn of non-functional code you have to write in your app. You can put D-ASYNC and dapr together - they are not mutually exclusive ;) And I think you are right, it's hard to figure if a tech can solve your problems without trying them.
D-ASYNC certainly seems an interesting tool! I've got a new GitHub repo I'm using to have a play around with some of the Dapr functionality (I'll probably implement the Product/Order validation from this post as a really rudimentary example.
gRPC is certainly a something interesting. As you said, while it gives you pretty damn good reasons to use it, it certainly has it's downsides. The last project I worked on, I had to refactor existing REST APIs to gRPC. While it was fun to watch everything works like a charm, it definitely takes a toll on time. But when you get used to it, and reusability kicks in... It feels, okay. I had a rough time here trying the tech for the first time not knowing anything, but you kinda forget it 😂. And I just used the request/response model it offers. There's lot more to it. Just sharing my experience with the tech. Btw, try rsocket if you get some time. It uses websockets instead of http. I think you can add that to the article as well. 👍
Yep, think it will be the same as anything. When I first started working with Event Buses it used to take me forever to set everything up (events, handlers, subscribers etc). Now I think I could make a pretty good job of doing it with my eye closed.
gRPC just needs some practice :)
Why not use GraphQL? From graphql.com :-
"A query language for your API
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
Ask for what you need,
get exactly that
Send a GraphQL query to your API and get exactly what you need, nothing more and nothing less. GraphQL queries always return predictable results. Apps using GraphQL are fast and stable because they control the data they get, not the server."
Thanks for the reply Carl. I've heard a lot of good things about Graph QL, but didn't feel I had enough experience with the tech to include a worthwhile argument. I imagine the downsides are very similar to REST and gRPC though (explicit endpoints...)
good article. hope you can write about event bus more :)
I have another post lined up talking about exactly that :-) keep your eyes peeled