Solution: eth_getLogs, eth_getFilterLogs, and eth_getFilterChanges

The Filter mechanism is best when real-time latency matters. However, that isn’t needed in our case, and the session / WebSocket management is not worth the gain from polling. We can observe every block with getLogs by correctly tuning the “start” and “stop” block heights passed to getLogs.

Per the main ETH docs, Infura doesn’t support Filters. I have yet to check who else does or doesn’t support filters.

Secure WebSockets are a big tech psyop to make your code break. Why? Because having to manage the connection, which will disconnect at some point always, is not worth it. Spam poll and track your own uniques is my preferred pattern.

Your RPC provider must manage all your filters in memory, adding another dependency that could break. Your RPC’s load balancer, even with sticky sessions, can break. Then you’ll have sent your filters to box A, but are then LB’ed to box B, and your app suddenly has no filter context.

Solution: eth_getLogs, eth_getFilterLogs, and eth_getFilterChanges

The Filter mechanism is best when real-time latency matters. However, that isn’t needed in our case, and the session / WebSocket management is not worth the gain from polling. We can observe every block with getLogs by correctly tuning the “start” and “stop” block heights passed to getLogs.

Per the main ETH docs, Infura doesn’t support Filters. I have yet to check who else does or doesn’t support filters.

Secure WebSockets are a big tech psyop to make your code break. Why? Because having to manage the connection, which will disconnect at some point always, is not worth it. Spam poll and track your own uniques is my preferred pattern.

Your RPC provider must manage all your filters in memory, adding another dependency that could break. Your RPC’s load balancer, even with sticky sessions, can break. Then you’ll have sent your filters to box A, but are then LB’ed to box B, and your app suddenly has no filter context.