Lesson 137 - Rest vs. Messaging

Developers and architects are often faced with the age-old question: Should I use REST or messaging for my communication protocol? More appropriately, this question becomes more about whether to use synchronous or asynchronous communication. In this lesson Mark Richards discusses some of the trade-offs and implications of each of these communication styles to help you decide which one is most appropriate for your situation.
Reference Links:
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2

[@farrukhijaz]

Great video as always! Up to the Mark :)

[@stjepankarin]

Thanks for the nice video. As always, it depends on tradeoffs you want/need to choose for whatever use-case that needs to be supported. Regarding wishlist/catalogue example, and given we’re ok with eventual consistency, I would consider storing all necessary data needed for it to function as needed in a db belonging to the wishlist. That part should of course be more of read-mode, as catalogue is considered to be “master”-data in this case. Anytime a product in catalogue would update, I would make sure that ProductUpdated event ends up as a message on a bus, and then wishlist (and whoever else needed) could pick it up and update its data accordingly. Maybe that is what you’re also trying to explain in your east-west communication analogy? I do see by the graphics, that both have their own dbs/tables.

[@staskrakovsky9872]

Awesome lesson!

[@GauravSehrawat8888]

Dankejewel van Amsterdam

[@nullentrophy]

Thank you sir

[@matthiashjalmarsson4121]

In your last example with Wishlist and Catalog, wouldn't the request to the Catalog be synchronous? Surely Wishlist service has to block until the response has been received. So I'm not really sure what "messaging" provides in this context. Couldn't the Private API be REST as well? Or is the overall argument that it's easier and quicker to implement and maintain a private api over messaging?

[@markrichards5014]

It's more the latter (easier with messaging). Private REST API's are hard to govern and are more costly. Furthermore, with the request/reply, Wishlist can do work while the catalog is retrieving its information (similar to how futures/promises work in non-messing pseudo-sync situations)

[@markrichards5014]

@Krishna Gogineni See lesson 1...

[@rishabmanocha5732]

Could you give feedback if this would instead be a more valid solution? The Product service can broadcasts the added/updated product payload to the message queue everytime a PUT/POST call is made to it. The wishlist service listening to this will persist the description field that it needs from that payload and will never have a request-time dependency on the product service being available? Curious to know if there's a drawback to this approach?

[@berntrune]

Thanks again for a great video. Of course it depends, but would you normally use rest between an orchistrator service and the downstream services, due to the north/south "rule"?

[@markrichards5014]

Once you reach an orchestration service, the "north south" communication stops and the "east west" begins, so no, I would not normally use rest (again, as you said, it depends...).

[@razean22]

Interesting, an introduction to what you mean by asynchronous and synchronous would have been nice though. It seems that in the context of this video they are very different from what they are in a programming (let's say Promises in JS or async in python)

[@markrichards5014]

Good point; request/reply messaging is not really "asynchronous communication" because I have to wait for the response before continuing. With true async, I don't have to wait; I can respond to the user, and if needed, wait for a response on a separate message challen without having the make the user wait.

[@zaytsevand]

👍 actually, that's pretty good observation. With async in programming languages we've often get a state machine managed by the execution environment. In the async communication that state machine is often overlooked, nevertheless should also be present, but it's up for us to implement it

[@HiOctaneVideoShare]

Wait, how does messaging creatre "private api"? And how does this "private api" created by messaging know which fields to message back to Whishlist Service?

[@markrichards5014]

The "private API" is formed beneath the public API gateway by having services communicate through messaging. It's private because the messaging endpoints are not made available to the public - only internal services know about these from an inter-service communication perspective.

[@CrownlessX]

Why not gRPC instead of REST?

[@markrichards5014]

gRPC is a point-to-point persistent http2 connection using protocol buffers. While it is significantly faster than REST, it unfortunately couples services together because it is an RPC call (IOW using stubs). Also, gRPC alone doesn't support load balancing-you would need to use gRPC-LB instead.