# EVM getLogs vs getFilterLogs

By [skynet](https://paragraph.com/@mmorrell) · 2023-06-04

---

“So you want transaction data from the ETH blockchain…”
-------------------------------------------------------

Solution: [eth\_getLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getlogs), [eth\_getFilterLogs](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterlogs), and [eth\_getFilterChanges](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getfilterchanges)

* * *

Why eth\_getLogs is my preferred choice
---------------------------------------

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.

### Filter support is weak

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

### WebSockets make your code break - prefer getLogs

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.

### Filters require RPC state

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.

---

*Originally published on [skynet](https://paragraph.com/@mmorrell/evm-getlogs-vs-getfilterlogs)*