Asynchronous backend processing with long polling

Key Takeaways

So what you can do is essentially send a request but immediately respond back to the client with an ID of the job that has been created for the client says hey listen I put your request in a queue for further processing I did not process it immediately but I'm going to process it later. Now, later could be in a second, could be in an hour. So, here's an ID, a GUID, a UU ID. Come back with me to check the status. On the older model, if you send a request and you you want to wait for that response, if your connection closed as a client, what after you send the request in the normal request response model where the act the backend actively generates the response for you on that particular connection, don't you die as a client? You just disappear. There is no way to get that response. But this with this long pulled model after we turn this request response into a scalable you know predictable if you will backend model we also have resumability in this long response. Now even if the client has disappeared connection has died for anything I don't know the middle you know the middle boxes decided to kill your connection because you didn't send keep alive messages or it was technically ignoring keep alive messages for any reason and that just destroys your connection just just removes the knowledge of your connection existence and then you're done. So you come back with a new connection. What you do in this log pole model, you just come back with this uh your ID, your unique identifier that that the server gave you. It says, "Hey, is it back?" And you just resumes a new long poll session. And if you were lucky and you came back, the the server will say, "Oh, I'm not keeping your stinking jobs there forever." That cuz it has something you have to keep in mind, right? So you set an expiry day date for the for those responses and you can just delete them after