Techie, interested in all things Tech. Always ready to connect and collaborate on some good projects.
Hire Me: https://www.upwork.com/freelancers/~0111a5bb58b558dd6b
Location
Mumbai
Pronouns
He / His
Work
Freelancer on Upwork (https://www.upwork.com/freelancers/~0111a5bb58b558dd6b)
Websocket with API Gateway - Lambda is async anyway. But my main concern in this application was resilience - without the client worrying about retries. Not really worried about the feedback.
The original application had Lambda picking directly from the API Gateway. It had a complex processing logic - that would often fail halfway. Error handling was messy because of this. So I moved it to this architecture where the input request is baselined in the DB - leaving the client free of any error handling responsibility.
Additionally, as the Lambda processes the request, it updates the DB record with the status. This helps it resume the processing if it errors half way. I know we can do this partly in Step functions. But the functionality is pretty complex and interwoven, so I had no option but to do it in code.
Do suggest if there is a better way to solve this problem - Resilience in Web sockets - with no retries on the client.
I would say that depends if you need a feedback at all. Mostly cases you can return http 201 and/or refresh the page and reload you data from the backend. A websocket feedback does not make sense in my view since its way more complicated and makes it synchronous somehow. You can then check the error state then.
Thanks Rolf for your inputs.
Websocket with API Gateway - Lambda is async anyway. But my main concern in this application was resilience - without the client worrying about retries. Not really worried about the feedback.
The original application had Lambda picking directly from the API Gateway. It had a complex processing logic - that would often fail halfway. Error handling was messy because of this. So I moved it to this architecture where the input request is baselined in the DB - leaving the client free of any error handling responsibility.
Additionally, as the Lambda processes the request, it updates the DB record with the status. This helps it resume the processing if it errors half way. I know we can do this partly in Step functions. But the functionality is pretty complex and interwoven, so I had no option but to do it in code.
Do suggest if there is a better way to solve this problem - Resilience in Web sockets - with no retries on the client.
I would say that depends if you need a feedback at all. Mostly cases you can return http 201 and/or refresh the page and reload you data from the backend. A websocket feedback does not make sense in my view since its way more complicated and makes it synchronous somehow. You can then check the error state then.
The approach all behind that is a Saga
It does not make it synchronous, in some cases you want to inform the end-user about the status and such a websocket feedback loop makes sense.