search

Stakely / web3-load-balancer-configuration

Public configuration files for the multi-chain inteligent load balancer
10 stars 12 forks source link

Add quasar load balancer nodes #9

Closed pablin-10 closed 1 year ago

pablin-10 commented 1 year ago

All endpoints added here were taken from https://github.com/cosmos/chain-registry/blob/master/quasar/chain.json

iicc1 commented 1 year ago

Many thanks for aggregating all the endpoints, you saved us a lot of work. We are in the progress of deploying the code so the load-balanced endpoint will be published soon

sascha1337 commented 1 year ago

any chance of letting us know, what underlaying reverse proxy solution you are using behind the scenes ?

would be quite interesting to know. HAproxy, nginx, traefik, … especially, i would love to know, how you did solve / bypass the issue with the sequence problematic - most raw non-custom-logic healthcheck load balancers are causing problems,

when the load balancer is routing subsequent tx broadcasts to different RPC endpoint. Once a connection is established, does the load balancer stick the ip/tcp handshaked session to the first allocated RPC, internally ? Aka sticky session for time Xseconds // hours // ip ?

Thanks - i mean, open sourcing the real configuration and infra setup would save tons of time, including helping the ecosystem insanely much - the hardcoded RPC/REST/LCD/GRPC’s inside dapps,

… having that one offline suddenly, completely kills any possibility to interact with any dapp that is built that trivial way. Incl. FUD of people, that “the chain is overloaded / down” due to ONE (XD) endpoint having some hick-up. Or CORS errors due to browser security differences between devices.

Thanks and best regards, ~1337

On Tue 9. May 2023 at 19:08, Ignacio Iglesias @.***> wrote:

Merged #9 https://github.com/Stakely/web3-load-balancer-configuration/pull/9 into main.

— Reply to this email directly, view it on GitHub https://github.com/Stakely/web3-load-balancer-configuration/pull/9#event-9199712343, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6MWVMMSL5M7YYYDNDRURDXFIQSNANCNFSM6AAAAAAXTVMZAE . You are receiving this because you are subscribed to this thread.Message ID: <Stakely/web3-load-balancer-configuration/pull/9/issue_event/9199712343@ github.com>

iicc1 commented 1 year ago

any chance of letting us know, what underlaying reverse proxy solution you are using behind the scenes ? would be quite interesting to know. HAproxy, nginx, traefik, … especially, i would love to know, how you did solve / bypass the issue with the sequence problematic - most raw non-custom-logic healthcheck load balancers are causing problems, when the load balancer is routing subsequent tx broadcasts to different RPC endpoint. Once a connection is established, does the load balancer stick the ip/tcp handshaked session to the first allocated RPC, internally ? Aka sticky session for time Xseconds // hours // ip ? Thanks - i mean, open sourcing the real configuration and infra setup would save tons of time, including helping the ecosystem insanely much - the hardcoded RPC/REST/LCD/GRPC’s inside dapps, … having that one offline suddenly, completely kills any possibility to interact with any dapp that is built that trivial way. Incl. FUD of people, that “the chain is overloaded / down” due to ONE (XD) endpoint having some hick-up. Or CORS errors due to browser security differences between devices. Thanks and best regards, ~1337 … On Tue 9. May 2023 at 19:08, Ignacio Iglesias @.***> wrote: Merged #9 <#9> into main. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6MWVMMSL5M7YYYDNDRURDXFIQSNANCNFSM6AAAAAAXTVMZAE . You are receiving this because you are subscribed to this thread.Message ID: <Stakely/web3-load-balancer-configuration/pull/9/issue_event/9199712343@ github.com>

Hi Sascha! We have developed our custom load-balancing logic implemented in JS for this since standard solutions weren't enough for this purpose. We do not have that sticky session feature. We thought it wasn't necessary since transactions are independent, but please correct me if I'm wrong. Regarding CORS, we perform some modifications to the response headers returned by the nodes so that issues cannot arise.

We currently have no plans to open-source our code, we are in the progress of doing a full refactoring of the code and we may think about it in the future.