chore: move websocket proxy #203
Conversation
feat: initial project setup
chore: require 1.85
chore: add readme
chore: add support for hostname prometheus tag and global tags
Support Multiple Upstream WebSocket Connections for HA Setups
* feat(PROTO-945): implement Redis-based rate limiting and update dependencies - Added RedisRateLimit for distributed rate limiting, allowing connection tracking across multiple instances. - Updated Cargo.toml to include new dependencies for Redis and related packages. - Enhanced README with Redis integration instructions and usage examples. - Modified main.rs to support Redis configuration via command-line arguments. - Updated Cargo.lock with new package versions and dependencies. * Add redis-tools to github action for test runs
fix: parse multiple upstream url
* reset redis counters on boot * updates to use heartbeat/cleanup mechanism for tracking * pr comment updates, add tests, move sempahore
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
| Builds of the websocket proxy [are provided](https://github.com/base/flashblocks-websocket-proxy/pkgs/container/flashblocks-websocket-proxy). | ||
| The only configuration required is the rollup-boost URL to proxy. You can set this via an env var `UPSTREAM_WS` or a flag `--upstream-ws`. | ||
|
|
||
|
|
||
| You can see a full list of parameters by running: | ||
|
|
||
| `docker run ghcr.io/base/flashblocks-websocket-proxy:master --help` | ||
|
|
||
| ### Redis Integration | ||
|
|
||
| The proxy supports distributed rate limiting with Redis. This is useful when running multiple instances of the proxy behind a load balancer, as it allows rate limits to be enforced across all instances. | ||
|
|
||
| To enable Redis integration, use the following parameters: | ||
|
|
||
| - `--redis-url` - Redis connection URL (e.g., `redis://localhost:6379`) | ||
| - `--redis-key-prefix` - Prefix for Redis keys (default: `flashblocks`) | ||
|
|
||
| Example: | ||
|
|
||
| ```bash | ||
| docker run ghcr.io/base/flashblocks-websocket-proxy:master \ | ||
| --upstream-ws wss://your-sequencer-endpoint \ | ||
| --redis-url redis://redis:6379 \ | ||
| --global-connections-limit 1000 \ | ||
| --per-ip-connections-limit 10 |
There was a problem hiding this comment.
I'll update the image URLs when I add the docker deployment and have new images
|
The CI issue for contender is fixed in #204 |
|
Thanks for looking @0xKitsune, happy to add it as a workspace setup if ya'll prefer. cc @ferranbt if I understood, you had a preference to keep them separate/just add a subfolder? (Though I may have misunderstood) |
Sounds good, yeah I think a workspace would be best here rather than standalone crates. Workspaces will simplify dependency management across services without duplicating deps in |
Yes, this was my initial suggestion to keep the PR as lean as possible. If we have to create a workspace we have to restructure everything right? @0xKitsune |
Setting up a workspace does not require major restructuring, however happy defer this to a follow up PR to keep changes minimal. The only change needed is to move the existing crate into a new directory (e.g. rollup-boost/), update the existing |
|
I'll me make the workspace changes on this PR. If it results in too large a change we can revert the commit + merge separately. |
|
Hi @danyalprout, is base/flashblocks-websocket-proxy basically closed to changes while this move is happening? If I'd like to make changes to the websocket proxy, should I just fork the branch for this PR instead? |
|
@paranoiacblack that's right, I'm going to archive that repo later today |
Description
Initial pass for #202