Timeline for Command Waiting On Event Sourcing Micro-services
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 2, 2020 at 17:02 | vote | accept | Matster2 | ||
| Jun 6, 2019 at 13:24 | comment | added | Cormac Mulhall | This is the advantage of REST but it does make your systems more complicate at the initial design stage than something simply like RPC, so it you don't actually need any of this it is ok to move away from REST to something else. Better to use something like RPC fully than to use REST/HTTP but try and get it to work like RPC, if that makes sense | |
| Jun 6, 2019 at 13:23 | comment | added | Cormac Mulhall | Why do that? Well because it means the only think the client has to know about is the states the order can be in, it doesn't need to care about what the server has to (implementation). So you can completely change how orders are placed on the server and the client won't care. On the other hand if the client did know and you changed how the server placed orders then you would have to change the client as well. The client would need to know that first you do X and then you do Y and then you have to do Z. And when you change that to Z then Y you have to re-write your client. | |
| Jun 6, 2019 at 13:21 | comment | added | Cormac Mulhall | The purpose of REST is to de-couple the state update (hey this is the new state of the resource) from the implementation on the server of how the server does that new update. This is the difference between REST and something like RPC. So in REST the client should not care at all how the sever is going to do anything. It only cares about the state of the resources. So for example, the client does not ask the server to place an order. The client puts the "order" resource in the state of "placed", PUTs this to the server and lets the server figure that out. | |
| Jun 6, 2019 at 10:26 | comment | added | Matster2 | Thank you this is really helpful. I always came at it from the point of view, (probably unconsciously more command based that it should be). Im going to do this thing, (e.g. place/add an order). You need to validate it, do your stuff and tell me if it worked. It due to not wanting any bad data in :P | |
| Jun 6, 2019 at 10:16 | comment | added | Cormac Mulhall | Even though the server may take a long time to update itself, as far as the client is concerned it just needs to know, relatively quickly, if the server is going to accept this new state for the resource. The client doesn't actually care when the server gets its act together, it just cares if the server will accept this HTTP request (eg PUT) to update the state of a resource, because from the clients point of view it simply needs to care if it needs to do something different to get the server to accept the new state of the resource. Something to keep in mind when designing REST systems | |
| Jun 6, 2019 at 10:14 | comment | added | Cormac Mulhall | Well something to keep in mind is that REST is about state transfer. So it doesn't really have a concept of "callbacks" or things to be triggered when something else happens or long running requests. In HTTP (which is a REST protocol) the client says "Hey server, here is the new state of resource X, update your copy of this resource". The response is simply the server either say "Ok I will" or saying "No I won't" for various reasons (4xx or 5xx http responses). There is no concept of "Ok I will try to but it will take a while, hang on while I do some stuff" in HTTP/REST. | |
| Jun 5, 2019 at 21:19 | comment | added | Matster2 | Coming from an object oriented mindset and a general case polling is bad, it initially seems quite difficult to accept, but It understanding that these are events and events can take time to process. nothing is instant. Polling is your friend as it will allow you to keep tracks on an event. | |
| Jun 5, 2019 at 21:19 | comment | added | Matster2 | it seems to be about submitting a command (e.g post of an order) and then polling another resource (which will be given to you via the location header) or will event give you links to other resources to progress a process. | |
| Jun 5, 2019 at 21:18 | comment | added | Matster2 | Thank you for you reply. I currently have another question to client communication posted on stack overflow and both of your answers are slowing making the picture more clearer. Your answer on the first point seems to help me understand that its not really about getting a response immediately anymore. The response you aim to get in an event based architecture is a created or accepted to signitfty the command has been accepted and a side effect is its going to created that resource in an initial state firing of an event of order created. | |
| Jun 5, 2019 at 17:25 | history | answered | Cormac Mulhall | CC BY-SA 4.0 |