Ponder

The ponder client library will be very, very good

Write queries in your frontend codebase, type-safe with no codegen, realtime/reactive by default

Coming soon to a browser near you

Building ponder.sh. EVM, TypeScript, open-source enjoyer.

Just my, probably not too smart, opinion. But I would love more to have the ability to customize the GQL schema that ponder generates or at least hook up my GQL resolvers to it. It feels somehow more reliable aproach than a separate library with own syntax. Also, the are plenty of tools to make usage of GQL easy in most of client-side codebases.

Blockchain developer, cloud engineering enthusiast, beginner crypto investor

First, regarding the GQL that Ponder provides. It is cool, really cool but lacks  some important features what probably detracts users from using it. What additional GQL features I would love to have when working on a project with Ponder:
- Add an additional field to the GQL Object Type + perform sorting and filtering based on this field. Real work use-case might be a total number of  transactions per user and select the top 5 users by the number of transactions;
- Write custom queries that have connection to other object types. For instance I want to somehow specially select ERC20 transfers and for that I want to write a custom resolver, but also I want to resolve other entities that are related to the transfer (transaction data for instance) without explicitly doing that in the resolver (by utilizing the way how GQL resolvers do cascade work);
- Write "where" conditions for parent objects based on child objects;

I did a small POC based on drizzle + yoga + graphql NPM package. I used a different package for generating GQL schema from the drizzle one, but it should not make a significant difference.

Here is the repo: https://github.com/AnotherFullstackDev/drizzle-gql-generation-with-extension/blob/main/src/index.ts.

Quick conclusion: If Ponder can expose the generated GQL entities the users should be able to extend the schema without any custom tools just with the API that graphql package provides.

Deeper look into points:
- I seems that graphql package provides an API to get an existing object definition so it is possible to just "spread" this definition + add own fields with args, resolvers, etc..;
- I think it is possible to provide parent objects filtering based on child objects and reuse the where input types for child objects (I did it in the repo) so it should not be cumbersome to implement and use;

I'm super glad to know that you (or anyone else) think of it. 🙏

Appreciate the feedback! Do you have experience with extending GraphQL schemas? We'd like to support, just not sure how best to do it.

True that GraphQL has a mature ecosystem, but from what I've seen, a very small # of ponder users are using GraphQL anywhere (else) in their stack, if that makes sense.