Nice idea and solution, although you had to change the server API as well.
I guess before you had a single resource, like POST /evaluate/1 and then turned it into a batch system.
The drawback of your system is that you need a "god object" that keeps track of all the input data but it's a solid idea to avoid duplicate calls. If more than one widget depends on "state A" then you end up asking the server about it only once.
I saw you tested also Promise.all :-)
A possible alternative, to limit the amount of connections to the server, could have been HTTP/2's multiplexing (while keeping the single resource) paired with caching.
Multiplexing opens one single TCP connection per origin, so you shouldn't have the issue of too many widgets connections on the same page.
Caching allows you to avoid evaluating the same value twice on the server (even if introducing caching you get another set of problems).
The only issue of your solution, correct me if I'm wrong, is that if the batch call fails, it fails for every widget on the page. In the HTTP/2 scenario if one the HTTP calls fails, the others go on indipendently.
Preact - Next.js - Deno - SSR - SSG 💻
Open source 📂
Machine learning 🤖
Books 📖
Sport 🏃♂️
Nature 🌱
Focus on being useful. I contribute AMAP to the OSS community. Love learning by doing.
Thank you for the comment. I just learned something new 😊 I'm going to start learning HTTP/2 to understand how multiplexing works.
My solution was thought for a project that uses AWS lambda on back-side. I'm not sure that AWS lambda supports HTTP/2, but I'm going to investigate! I like your proposal.
Nice idea and solution, although you had to change the server API as well.
I guess before you had a single resource, like
POST /evaluate/1and then turned it into a batch system.The drawback of your system is that you need a "god object" that keeps track of all the input data but it's a solid idea to avoid duplicate calls. If more than one widget depends on "state A" then you end up asking the server about it only once.
I saw you tested also Promise.all :-)
A possible alternative, to limit the amount of connections to the server, could have been HTTP/2's multiplexing (while keeping the single resource) paired with caching.
Multiplexing opens one single TCP connection per origin, so you shouldn't have the issue of too many widgets connections on the same page.
Caching allows you to avoid evaluating the same value twice on the server (even if introducing caching you get another set of problems).
The only issue of your solution, correct me if I'm wrong, is that if the batch call fails, it fails for every widget on the page. In the HTTP/2 scenario if one the HTTP calls fails, the others go on indipendently.
Thank you for the comment. I just learned something new 😊 I'm going to start learning HTTP/2 to understand how multiplexing works.
My solution was thought for a project that uses AWS lambda on back-side. I'm not sure that AWS lambda supports HTTP/2, but I'm going to investigate! I like your proposal.
It's just an idea, your solution might be enough for your use case for a long time. Worst case scenario as you said: you learn something new :-)
AFAIK API Gateway does not support HTTP/2 :-(