REST APIs for Microservices? Beware!

[@Jrpyify]

This is very succinct. To think I spent a lot of time last year trying to explain the pros/cons of call and response model vs orchestration model for an ecommerce cart and order system, when I could have just linked this video 😅

[@morespinach9832]

Orchestration means many things, apparently.

[@alexsiuwh]

This is a very valid issue coming into micro services design. I came across to actually merging several services into one on a high transaction volume system. Thanks very much for sharing

[@CodeOpinion]

Great to hear!

[@alokrm]

Pretty good explanation. You actually explained pretty well the MS architectural challenges and how to solve them. Looking forward for more videos . Thanks

[@CodeOpinion]

Appreciate the comment!

[@stefangabor5985]

Hi Dereck, Super clear explanation. It is the 1st video which clearly outlines the need for events. Great Job!

[@CodeOpinion]

Glad you enjoyed it!

[@mikemccarthy9855]

8:26 "If you have services that are making synchronous calls to other services to get data you may want to look at boundaries to see if they're actually correct." This is the problem with REST API's and microservices. You need API's for UI's to compose together a page of data from different services. Where most people go wrong is those same API's are then used for exactly what you said in your video, for getting data from other services for the currently executing service to do its job. At the heart problem is not understanding CQRS and how that translates into a microservices architecture. The API's that get data from microservices are CQRS "reads". Those API's are not to be called by other services. Why? Because by doing that, you've essentially opened the door to logical coupling at the data level. All the work you did to separate the data and encapsulate it into each service is essentially undone when you allow service A to call service B's CQRS "read" API in order to get data. What will service A do with that data? Most likely, persist it. If each service is doing this, then all autonomy, both at the logical level and the physical level is gone. Another way to think about it is when you are in a given service executing a business operation, you are essentially processing a CQRS "command" not a CQRS "read". All the data to process that command should be present in that service, you should NOT be reaching out to other services to get data you need (CQRS "read") while in that operation. If you do this correctly, you'll start to see the way you achieve read/write separation in your architecture (CQRS) is the API's become your "reads" and the messages become your "writes".

[@CodeOpinion]

Ya, I like that you just said all the data you need to process command should be in that service. I didn't say that exactly, but that's what I meant from what you quoted. Appreciate the comment!

[@calvinzhu7438]

First of all, it is very good video to expose all the concerns of Microservices which exposed with REST APIs. And I guess it would be more durable to implement WCF web services instead of Rest API for internal apps. Or maybe messaging queues instead of rest apis ?

[@CodeOpinion]

Anything that is a direct network request/response from service to service is going to have the problems outlined. Decoupling via asynchronous messaging removes the temporal aspect.

[@iandrake4683]

Nice video. When devs at my client talk about micro services, this is one of the conversations I try to have. I ask them to define the transactional boundaries and to be realistic about the current interdependency between silos. This usually kills the enthusiasm as I do not believe they are not a good candidate for micro services anyway.

[@CodeOpinion]

Yes is a required conversation to get boundaries in order. There will be required communication between services for a long running process/workflow, however these can generally be done via messaging.

[@gigiduru125]

also what if those boundaries change in the future?

[@BinarySpike]

Derek: "Do you know what the default timeout is?", Me: "Yes ☹"

[@robertsedgewick1266]

Excellent explanation. Your channel is a gem, thanks for sharing!

[@CodeOpinion]

Glad you think so!

[@efrenb5]

But now you've coupled your whole system to the message broker. What happens when that guy breaks? You end up in the same situation: full system fire because the broker is down.

[@CodeOpinion]

Generally you persist messages locally before going to the broker for this reason. Avoiding a distributed transaction with a broker. Most messaging libraries support it. Check out my video on the outbox pattern. kzbin.info/www/bejne/q2nJgKGudt1-fs0

[@CassioRogerioEskelsen]

No system is perfect, but the chances of a well-configured broker going down are less than a poorly behaved microservice to stop an entire business process running. And it is very easy to implement contingencies.

[@evilroxxx]

You could also have broker redundancy by implementing primary and replicas with automatic failover

[@dusan-minic]

Really getting valuable insight from this channel Distributed services are my main focus lately, and your videos are really concise and well explained. Good job.

[@CodeOpinion]

Thanks! Glad they are helpful

[@thilehoffer]

Great video. Good, old fashioned class libraries have been working fine for my team for years.

[@CodeOpinion]

Meaning all in-process in a single transactions? It can work, and it's all trade-offs. I've been thinking about creating a video around what those trade-offs are and why you might want to stick with a monolith or microservices, or where I've been advocating a loosely coupled monolith, which is kind of in the middle.

[@robert5763]

@@CodeOpinion I think such video would be valuable so consider making it. I would also like a detailed video about how to handle compensating transactions and the edge cases such as payments.

[@rafaspimenta]

Very nice article! One option that I use for some cases is create a cache for other microservice datas. So, I get the data from the cache instead of perform a http request. The cache is updated via event message. Thanks

[@YoutTubeHandle]

Great video. Short and to the point...not sure why 3 dislike. It's really discourage the creator if you simply hit the dislike without any comment about why.

[@CodeOpinion]

It's fine. If someone disagrees, they can dislike. A reaction is better than no reaction.

[@liam3284]

I have seen this go wrong. Storage array was under load, database took a while to complete. service b times out waiting for service a, which eventually completes the transaction. Service b then sends the same request again, where service a makes a duplicate entry.

[@CodeOpinion]

Indeed. "failure" response when the request doesn't actually fail.

[@fabriciopontesdearaujo7591]

Could be an interesting idea in your example to make warehouse being implemented in a interface/service manner: API just feed an execution queue and return an receipt to sales to it request results in another API call? In that way, the timeout problem disappear since the return of the initial call is just creating the queue item instead of executing the whole task. Last system I developed it worked very well.

[@fabriciopontesdearaujo7591]

I discovered your channed today. Very good video.

[@CodeOpinion]

Thanks for the comment. I've done a bunch of videos, most related would be the video on Event Choreography & Orchestration: kzbin.info/www/bejne/qICcc4upoZl0g7M

[@vivienh.missamou208]

you'are lucid.thanks

[@xReDCrIsTx]

I didn't understand how to fix distributed transactions. I mean, I understand the issue, not the solution haha. For instance: I have 3 microservices, and they receive a request that is valid for microservice A and B but not for C ( not because C is slow or down ) the request itself is incorrect for that MS. In that case, the right approach to fix that would be to send a rollback transaction to all microservices involved in that transaction. Right? Amazing video!!! Thanks!

[@CodeOpinion]

Check out this video on event choreography and orchestration kzbin.info/www/bejne/qICcc4upoZl0g7M

[@xReDCrIsTx]

Thanks!!

[@louistiches4810]

Why do they need their own database? It feels like I am just managing more tiny monolithic apps. I am very new to microservices and I have only really created B2B applications for orgs that do just fine with a monolithic ROR app.

[@francescodente2876]

Hi Derek! I was wondering how to go about notifying the frontend of an event that occurs within the execution of a saga. Using the example from the video, let's say the frontend sends an http request to the sales service asking to place an order. From what I understood, the request immediately returns successfully after starting the saga. Now, I'd like the frontend to get notified when the shipping label is created succesfully. How is this done if the UI is not aware of the internal communication between services? Thanks in advance.

[@CodeOpinion]

Events! Having a component in your UI be handling events for this purpose. If we're talking web or mobile frontend, like to have a consumer at the web application level to pass down the event to the frontend/UI via something like websockets. If you're using .NET that would be SignalR.

[@jeyfus]

@Dr3w 97 I’m not sure Kafka is a good fit in this kind of interaction. It is internal to the system and should stay abstracted IMHO . A Websocket or even a long pulling based implementation would be a better fit

[@vadimprudnikov9072]

Very nice video, thanks! :) Maybe it's worth saying some terms like "circuit breaker" so people will search for it...

[@CodeOpinion]

I mention circuit breakers, retries, fallbacks, etc. in this video when talking about fault tolerance kzbin.info/www/bejne/iZbWdox-fM2fgrM

[@miyazakizachary5108]

Love your presentation. I wonder do you have any idea to create a video talking about service bus vs message queue. What decision we should make on this choice. Hopefully, you could consider my proposal. Thanks.

[@CodeOpinion]

Funny enough I was thinking of this yesterday. I'll be adding to my list of future topics.

[@vishnuvardhanreddy220]

+1

[@srik790]

Great video again... Thanks.. Waiting for your video how to handle task based UI/UX to create new product and it's SKU...

[@CodeOpinion]

It's in the list of videos to tackle!

[@KunalMukherjee3701]

These videos are gold, keep em coming

[@CodeOpinion]

Glad you like them!

[@fallonmassey4714]

Have you looked at Dapr? The issues with http/grpc communication still exists, but if you know what you're doing, it shouldn't be a problem. Dapr has messaging that allows you to switch out many different brokers(Redis, RabbitMQ, etc) without any loss of generality.

[@CodeOpinion]

Thanks for the comment. Ya, I'm looking to cover it sooner rather than later. Are you using it?

[@fallonmassey4714]

@@CodeOpinion Yes! After a rocky start, I've dropped my event bus built around .net core and RabbitMQ in favor of Darp's implementation, and have a sidecar for each of my services. I almost dropped it when initial explanations were not so clear, but I kept coming back and the documentation got a lot better.

[@jamesalcaraz8729]

Good stuff as always. On the case of async messaging, how do you satisfy the requirement of the consumer where the nature of the request is synchronuous. Example the UI needs a response the represents multiple details from different services. Not everything is a fire and forget so in those cases what strategy to use to build out the requirement?

[@CodeOpinion]

If the nature of the request is synchronous, make it synchronous. You don't need to fight it or force asynchronous messaging where it doesn't need to be. Check out this video where I talk about RPC vs Messaging: kzbin.info/www/bejne/gn6uh62dqs15rZY

[@hrtummala]

We can still work through Asynchronous messaging with combination of server sent events to UI to mimic synchronous api calls. But yeah it's adding complexity to your already complex stack 🙂. State management on UI should clearly have a error boundary when you make best effort for response but if it is not ever coming via server event then what's the fall back option.

[@sfcommand]

It would be a more solid opinion if you used the same failure modes for both rest and messaging examples...

[@CodeOpinion]

Elaborate by what you mean "failure modes"?

[@sfcommand]

@@CodeOpinion your examples such as "what happens when x service is slow, y service is slow", etc. Showing messaging succeeding with the exact same cases you used for sync ws calls seems like it builds a more solid foundation for ya.

[@CodeOpinion]

@@sfcommand I cover that in other videos, specifically talking about handling failures in a message driven architecture: kzbin.info/www/bejne/iZbWdox-fM2fgrM

[@krumbergify]

Thanks for a great video with clear explanations!

[@krystian5858]

Nice vid, as always, thanks!

[@CodeOpinion]

Thanks for watching!

[@ismile47]

What are disadvantages of messge borker communications , I pushed an event and wating for other event which I was expecting response if there delay or failure of pull those response or track th on failure? Please suggest this video is really help full

[@CodeOpinion]

Disadvantages of asynchronous messaging are just how it's a different mindset then synchronous request/response. Modelling things is different. Observability is key because otherwise debugging can be much more difficult.

[@ChanceMinus]

Fantastic video. Thank you.

[@CodeOpinion]

Glad you enjoyed it!

[@ericomfg]

I'm struggling with this example because it seems like such a good fit for a monolith! Maybe I'm biased, microservices add so much complexity for little benefit until your organization is gigantic..

[@CodeOpinion]

I agree that org structure matters and plays a role. I've created a few videos around what I call a loosely coupled monolith and also posted a video about starting with it. Check it out kzbin.info/www/bejne/kJDTm2Sjiql-mtk

[@timhosking]

It’s not a monolith. He has given a very poor example of a micro service and has fallen into the trap of designing the micro service to follow entities in the database, which is surprising given he has other videos where he talks about separating resources from the data model. Your natural reaction here @eric is correct. It’s a micro service. Don’t make the technology fight the business. Purchasing, inventory, warehouse, etc are all part of a proper business transaction. If you find yourself writing “sagas” you’ve made the services too micro. Make them match the business use case.

[@CodeOpinion]

@@timhosking As a bunch of my other videos have pointed out, focus on capabilities, not entities. A "product" entity can live in multiple services/boundaries and which has different capabilities. The capabilities are what define the service. Purchasing, Inventory/Warehouse, Sales all have different capabilities of a product. The cost owned by purchasing has absolutely nothing to do with sales. POs have nothing to do with Sales. Stock Count/Inventory Adjustments in a warehouse have nothing to do with Purchasing. But they are all related a the concept of a product. Almost all domain's I've worked in, there is a life cycle. Eg, from the moment and order is placed, to the moment it hits AR and the work hits AP. If you match that as a business case, you'll create a monolith. Which maybe totally fine depending on the goals of the system. If you create services, you're likely going to create a workflow either with event choreography or orchestration to handle that long running process (saga or process manager, depending on the term you live by).

[@s0psAA]

Has anyone even done two phase commits on rest api? Doest it go against the stateless nature of it?

[@CodeOpinion]

Check out this video I've done about Event Choreography & Orchestration kzbin.info/www/bejne/qICcc4upoZl0g7M

[@daretsuki6988]

This is amazing. Currently I'm trying to write a game as a distributed system. I'm gonna check other videos as well!

[@CodeOpinion]

Thanks. I've never been much for writing games. Totally out of my area of knowledge, but hopefully the videos help in some way.

[@derrick3534]

Love the explanation. I have a question. You make a good case for not using REST for a distributed system however, how do u deal with validation of form in put when using an asynchronous approach. For example, let's say a user wants to change his email but the backend needs to verify that that new e.ail doesnt already exists. If that new email does exist and u are using asynchronous REST or messaging queue, how does that work out?

[@CodeOpinion]

Some requests will naturally be sync request/response, as an example most requests from a UI. As your example, that call from the UI to the server is synchronous and that makes sense. Is placing an Order need to be fully synchronous? No. The request from the UI to the server is synchronous. But the server could enqueue a message to create the order and then immediately tell the UI/Client, "Thanks we've got your order and we'll let you know when it's processed". The order creation, payment processing, etc, can all be done asynchronously not blocking the UI/Client.

[@derrick3534]

@@CodeOpinion thanks I was thinking the same thing

[@phanuwatwattanapraya7998]

This really very useful video, thank you so much

[@CodeOpinion]

Glad it was helpful!

[@LawZist]

Hi Derek, From your professional opinion - what is the time duration you think a request should be made async instead of sync?

[@CodeOpinion]

I don't really know if the duration is the key factor. To me it would be more about does it need to be blocking? Meaning if a user is placing an order, does it really need to block the client because it needs to save the order, process the credit card, confirm with the warehouse all the items are in stock? No. That can all be orchestrated asynchronously. The benefit with moving to async is removing the temporal aspect where all services needed to be available and online for the process to complete.

[@LawZist]

@@CodeOpinion Thanks for the reply!

[@hectorluisbarrientosmargol9303]

As I'm watching this video I can't get CAP theorem out of my mind

[@CodeOpinion]

I did a video about it related to microservices. A distributed system in relation to CAP is different than large system that's decomposed into a set of distributed services. kzbin.info/www/bejne/hpirfqeDorihb9U

[@FecayDuncan]

I would use a process engine and implement a Saga pattern.

[@CodeOpinion]

In the portion of the video I mentioned messaging and gave an example of event choreography. I have a separate video on event choreography and orchestration here for those interested. kzbin.info/www/bejne/qICcc4upoZl0g7M

[@FecayDuncan]

@@CodeOpinion thanks, good one!

[@twiksify]

Great content, however consider mirroring the video of the face cam. Your sweatshirt is a giveaway, the logo reads "hsamedoc" instead of "codemash".

[@CodeOpinion]

I have it set this way so that when I look at my monitor, I'm looking in the same direction as the code. I often don't wear lettering anymore because I get this comment.

[@TheSurroundification]

I'd like to see a video about application interface architecture with middlewares between and based on REST most likely. Im finding myself in a lot of project lately where i have to build interfaces between two seperate systems via webservices (for example synchronizing integrations). Most systems have their own middleware and handling events and processes on both sides is kinda tricky, in most cases the other system is handled by other people. Is there some kind of best practice for building solid process oriented interfaces? I know it depends on the case but maybe you have some good ideas and best practices. Thanks

[@CodeOpinion]

I'm not entirely sure what you mean. Do you have a specific example that you can explain? Basically you have a service that's delegating between other services via HTTP? Is it for workflow?

[@TheSurroundification]

@@CodeOpinion Specific example would be an Interface for Incident Management Workflow/Process in two tools, customer and external supplier system. Synchronising status changes and updates event driven. Might be too specific for a video but im looking more for a high level abstraction how to build an event driven solution where the two systems are both responsible for their own internal workflows but interact with eachother. I hope this is alittle bit more clear? Thanks

[@CodeOpinion]

It is now, thanks for explanation. I'll put the idea in my list. Trying to think of exactly what the topic of that is. Do you control those other systems or no?

[@TheSurroundification]

@@CodeOpinion in most cases the updates or status changes are informative. Since workflows and processes in the other system might be different to the sender system, the actions are interpreted and handled by the other systems middleware or logic and then transformed into actions based on their business workflow. While writing all this, i see that this is very dependend on each case since every system is different. Thank you for the effort :D

[@evilroxxx]

@TheSurroundification you might wanna look into webhooks for something like that.

[@Crozz22]

How would you deal with the warehouse running out of items but there are still unprocessed orders in the queue? The user would have got an order received confirmation already, right?

[@CodeOpinion]

Take a look at my video on long running processes with Event Choreography & Orchestration. It's about having compensating transactions. Let me know if this helps, otherwise I'll create more content around it. kzbin.info/www/bejne/qICcc4upoZl0g7M

[@Crozz22]

@@CodeOpinion Thanks, that made sense. I might have changed up the order a little bit and waited for the warehouse to reserve the item before billing, but the principle would seem to be the same.

[@aadams99]

What if the services are not in the same data center (it will be difficult to use a messaging bus like RabbitMQ)? What about setting longer timeouts? What about placing a messaing broker behind a web api (or inside a web api layer) with the api acting as the orchestrator but still using res/res for serv to serv coms but the broker as state/persistance? If there's a timeout have the broker retry the service or a second using req/res? Basically what we need stateless req/res for service-to-service communication and a persitance store for keeping track of calls.

[@CodeOpinion]

Depends the broker. Something like AWS SNS can push to an HTTPS endpoints and AWS SQS supports VPC endpoints.

[@timhosking]

If you have a business transaction that has to put messages on a stack rather than implementing a software transaction to support then I think you have drawn the boundaries around your micro services incorrectly.

[@CodeOpinion]

While I agree that it's often likely boundaries are wrong, that's not the case all the time anytime you need to use messaging. I often use messaging within the same boundary to improve scalability. Also if you're integrating with an external system that you don't control (or from a different team) it can increasing reliability of your own service. Having said all that, they aren't the answer to all problems and in a many cases, you're likely better with a single schema and atomic transactions then creating a distributed system.

[@HelloThere-xs8ss]

Why not just sockets?

[@CodeOpinion]

Web Sockets or network (tcp)? Same situation as HTTP, if the service is down and or is degraded and cannot respond to your request, then you have to queue up those requests locally and retry them. Alternative is a message broker to handle that for you.

[@HelloThere-xs8ss]

@@CodeOpinion I was thinking of tcp. maybe theres no way around this kind of issue?

[@GCoda]

cap`n proto WTF

[@CodeOpinion]

It's still RPC

[@scdecade]

As soon as you say "each service has its own database" you caused yourself all the problems. Modern SQL databases are easily capable of handling multiple services.

[@CodeOpinion]

Sure a database could likely scale to handle the required load. Or it can't. Or storage requirements are not the same across all services. Or you don't want to be coupled by schema. Or you have teams per service and they can't deploy independently because you're coupled by schema and may break other services with a schema changes. Or the list goes on. Or none of the above is an issue and you can use a shared schema. As usual, context matters.