Content
@
0 reply
0 recast
0 reaction
Kevin
@typedarray.eth
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
2 replies
7 recasts
73 reactions
Another Fullstack Dev
@anotherfullstack
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.
1 reply
0 recast
1 reaction
Kevin
@typedarray.eth
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.
3 replies
0 recast
0 reaction
Another Fullstack Dev
@anotherfullstack
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;
0 reply
0 recast
1 reaction
