I just wanted to add to 2:00 that you may also want to record in the database the request's status (if the user has visibility on their request being made in the first place). This way that can query "What is the status of my request?" instead of wondering if it completed. Processing the request would result in altering its status.
great content, we have a monolith php system right now and our problem is solving the slowness of generating of documents. we cant change the UI without completing the whole process. any suggestion please. thanks
Thanks for the very informative video! Regarding the topic of the BFF, because the Query is still synchronous, I understand that the BFF improves on the situation where there's orchestration between a bunch of services, but isn't the client still in a blocking state? Is there a standard/common async way to make a Query from the client, or is it just in the nature of a Query to be synchronous, because it'd be waiting and in a blocking state regardless of whether the Query is processed sync vs async (due to the client needing the Query results)?
Yes, the client is still blocked by a synchronous call to the BFF. The BFF is just reaching out to all the of the other services, also synchronously to compose the result to the client. Queries are just naturally synchronous because you want to get a result.
I would not recommend BFF, because your would end up, most likely, with a monolith, and a single point of failure. You can potentially use GraphQL, but good luck with that. I would rather do the orchestration myself. It all depends by your starting point. Are you trying to move from a monolithic architecture to microservices? Or you are designing a new system from scratch? One of the first company to implement orchestration in Java was Netflix, but their solution was Java centric and could only be used with Java. I implemented the orchestration in a microservice framework I wrote in PHP. In PHP there was nothing, there is still nothing to be honest. I created an extension to Monolog, a library to handle errors, so I could propagate back on the calls chain the error, but I logged the error in New Relic, using an undocumented API. So in New Relic I always knew what was failing and when, and the failing service was logging the exception/error, meanwhile the others where reporting back a 501. It was a piece of cake, it works perfectly and it make it super easy to find where the problem is. Nowadays you can use Istio, a so called Sidecar proxy. It's agnostic, you can use it with all the programming languages, because it's effectively a proxy between your services. This enable you to implement microservices in different languages. Which you will probably not be doing, in any case. It support http(s) and rpg. If you have a chain of calls that is going over 2 services, you are probably doing something wrong.
What about maintaining state of the request? If it is a long running process you would want the UI to know a request was in process (if you navigated away from the page for example) and presented that information accordingly. Great video.
Yes you can maintain a state and provide that to the user. You can use orchestration or event choreography to keep a record of where along the business process is so you can present that to the user. Which would basically be exactly like what was shown in the AWS example.
@@CodeOpinion that's exactly what I'm looking to solve :) my 1 command needs to communicate to 2 external services (1 being an email 3rd party) I'm using the eshop example for inspiration. I'm also looking into using MassTransit to communicate to those 2 services. Just watched your webhooks service vid which is good, but if it's not bad practice for a service to push integration events to itself, I may just do that!
Is it too unnecessarily complex it take it off the events bus (inters-ervice communication) and then put it onto its own internal queue/topic even if it's for only like 1 action?
I just wanted to add to 2:00 that you may also want to record in the database the request's status (if the user has visibility on their request being made in the first place). This way that can query "What is the status of my request?" instead of wondering if it completed. Processing the request would result in altering its status.
I really hoped you will be making a video about this topic! Thanks Derek
great content, we have a monolith php system right now and our problem is solving the slowness of generating of documents. we cant change the UI without completing the whole process. any suggestion please. thanks
Distribute the workload and then compose it together at the end. You'd need some type of orchestration for that.
do you have a ddd guide for beginners?
Thanks for the very informative video!
Regarding the topic of the BFF, because the Query is still synchronous, I understand that the BFF improves on the situation where there's orchestration between a bunch of services, but isn't the client still in a blocking state?
Is there a standard/common async way to make a Query from the client, or is it just in the nature of a Query to be synchronous, because it'd be waiting and in a blocking state regardless of whether the Query is processed sync vs async (due to the client needing the Query results)?
Yes, the client is still blocked by a synchronous call to the BFF. The BFF is just reaching out to all the of the other services, also synchronously to compose the result to the client. Queries are just naturally synchronous because you want to get a result.
I would not recommend BFF, because your would end up, most likely, with a monolith, and a single point of failure. You can potentially use GraphQL, but good luck with that. I would rather do the orchestration myself. It all depends by your starting point. Are you trying to move from a monolithic architecture to microservices? Or you are designing a new system from scratch? One of the first company to implement orchestration in Java was Netflix, but their solution was Java centric and could only be used with Java. I implemented the orchestration in a microservice framework I wrote in PHP. In PHP there was nothing, there is still nothing to be honest. I created an extension to Monolog, a library to handle errors, so I could propagate back on the calls chain the error, but I logged the error in New Relic, using an undocumented API. So in New Relic I always knew what was failing and when, and the failing service was logging the exception/error, meanwhile the others where reporting back a 501. It was a piece of cake, it works perfectly and it make it super easy to find where the problem is. Nowadays you can use Istio, a so called Sidecar proxy. It's agnostic, you can use it with all the programming languages, because it's effectively a proxy between your services. This enable you to implement microservices in different languages. Which you will probably not be doing, in any case. It support http(s) and rpg. If you have a chain of calls that is going over 2 services, you are probably doing something wrong.
What about maintaining state of the request? If it is a long running process you would want the UI to know a request was in process (if you navigated away from the page for example) and presented that information accordingly. Great video.
Yes you can maintain a state and provide that to the user. You can use orchestration or event choreography to keep a record of where along the business process is so you can present that to the user. Which would basically be exactly like what was shown in the AWS example.
Nice explanation again
Glad you think so!
Thank you
Welcome!
Is it weird for a consumer to be the same service?
Not at all IMO. Ex, sending an email based on am event. Generation and sending of the email doesn't need to be another service
@@CodeOpinion that's exactly what I'm looking to solve :) my 1 command needs to communicate to 2 external services (1 being an email 3rd party)
I'm using the eshop example for inspiration. I'm also looking into using MassTransit to communicate to those 2 services.
Just watched your webhooks service vid which is good, but if it's not bad practice for a service to push integration events to itself, I may just do that!
Is it too unnecessarily complex it take it off the events bus (inters-ervice communication) and then put it onto its own internal queue/topic even if it's for only like 1 action?