typed-graphql-builder VS sq

I'm honestly pretty happy with TypeGraphQL. TypeGraphQL works code-first and lets you integrate request-scoped DI for resolvers, which makes writing more complex resolves significantly more pleasant.

Admittedly for the front end I couldn't find a satisfactory tool so I built typed-graphql-builder (https://typed-graphql-builder.spion.dev/). You do have to run it if your backend schema changes, but not when your queries change as the queries are written in typescript and inferred on the fly. (I should probably write a watch mode for the cli, that should largely take care of the rest of the toil when quickly prototyping)

Can we do projects that we think will stay at $0 but we still hope might gain traction?

OSS: typed-graphql-builder https://typed-graphql-builder.spion.dev/ is a TypeScript based graphql query builder.

It was inspired by tql (https://tql.dev/) but generates a much smaller client and has full, automatic type inference for query variables used in input objects.

FWIW I've given up the SQL query builder route and instead went with GraphQL query builder / Hasura route (https://typed-graphql-builder.spion.dev/).

Check this: https://github.com/typed-graphql-builder/typed-graphql-builder

Agreed. I'm working on a typed query builder for GraphQL and TS but secretly I'm a little mad that nobody gave some thought to making it easier to integrate in a type-safe way at least in the client languages

https://github.com/typed-graphql-builder/typed-graphql-build...

No docs yet, that's WIP

You can use my library sq which handles this exact use case with the PreparedQuery type. It allows you to build a query programmatically, prepare it and optionally rebind parameters by name.

Have you seen my library https://github.com/bokwoon95/sq? You can use it like database/sql and write plain SQL strings, only needing to provide a function that maps an database row to a struct and generics returns a slice of those structs at the end.

Also consider my library sq which handles dynamic query generation as well as data mapping. You may find it simpler than bun because it's a lot closer to database/sql (it doesn't require a special DB object, it uses a plain *sql.DB).

> I didn't see anything to help me build back graphs

Hmm you've certainly given me something to think about. Thanks.

BTW joins are not challenging, but you made me realize I didn't show any joins in my basic examples. Here is UPDATE with JOIN example: https://bokwoon.neocities.org/sq.html#postgres-update-with-j....

How does it compare to https://github.com/bokwoon95/sq?