Built out the Fuel indexer, a cross-chain EVM indexing service in Go that lets developers deploy their own indexers via codegen, generated GraphQL APIs, and dynamic Postgres instances.
The Fuel indexer is cross-chain EVM infrastructure: instead of a developer standing up their own indexing pipeline for every chain they care about, they describe the events and schema they need and the indexer generates the rest. I worked primarily on the Go service underneath that promise: complex concurrent code, macros, and codegen driving custom GraphQL implementations, backed by databases that had to hold up at scale and under high throughput.
The core design bet is that a developer defines a GraphQL schema for the data they want, and the indexer codegens the handlers, the dynamic Postgres instance, and the GraphQL API around it, rather than making them hand-wire a database schema, an ingestion pipeline, and an API layer separately and keep all three in sync by hand.
That codegen boundary is also where most of the hard engineering lives: concurrent Rust and Go code has to stay correct under real chain reorg and throughput conditions, not just in the generated-example case. I worked across the compiler team, the SDK team, and frontend to keep that boundary honest end to end, from the schema a developer writes down to the API they actually query.
The commercial case for a codegen'd indexer is time: every developer who would otherwise hand-build a database schema, an ingestion pipeline, and an API layer separately (and keep all three in sync by hand every time the schema changes) is a developer who ships their actual product instead of their indexing infrastructure. Collapsing three layers a team would normally build and maintain themselves into one schema-driven pipeline is what makes "deploy your own indexer" a promise Fuel could actually make to developers, not just a feature on a roadmap.