Why even use an ORM when https://sqlc.dev/ will generate everything from vanilla SQL?
Why make the frontend team write a Typescript client when https://goa.design on the backend will produce an OpenAPI schema they can just point a https://openapi-generator.tech at?
Why write out GraphQL boilerplate when https://github.com/99designs/gqlgen will take your GQL typedef and generate it all for you based on how you want it to look.
Why write validation rules when you can just define your input struct and let https://github.com/mustafaakin/gongular generate the rest for you?
Honestly, I'm loving this. I want to focus on the entities and business logic - not writing yet another handler/resolver for basic auth + CRUD work.
And I say it without being sarcastic but Go makes me miss C preprocessor and nothing should make anyone miss C preprocessor.
Funny considering how Rust does stuff.
Both approaches have pros and cons. One either digs through a shitload of macros, or commits explicit auto generated code.
Why is it a shame? Rely on macros and this is what you get:
1. Slow compile times
2. Unsearchable (grep, sourcegraph...) code
3. Magic codebases. Longer learning curve
To me, working in a large organization, those are big downsides.
Pretty easy to generate GraphQL (most fully featured extension), OpenAPI, Protobuf, etc. from your database schema. Ent also makes it easy to implement your own generators (e.g. OAS, glue logic, etc).
It's still a good option, just sad we keep inventing more abstraction layers that are unique in each language. That is a benefit of GraphQL typedefs, JSON, and SQL - it's the same in every language.
Also, Protobuf is another (not new) but good example of client and server side code generation which passed the time test.
Overall there are many reasons why I would like to generate code slightly differently from what is done in the lib, I wish there was a way to have a highly customizable code generation experience
I love learning about new frameworks/libraries in golang for exactly that reason of reducing boilerplate and spending more time on logic.
The project is still active. It seems that feature requests and issues are not being asked of the project.
Besides this project I like sqlc a lot but in both scenarios I was wondering how one gets started in code generation tooling? So that I could contribute, extend or even create my own (I.e. I would like to extend sqlc for better integration with FastAPI).
Then I would try to do something small to experience both libraries hands-on as otherwise it's hard to get the hang of it. Once you did a small project I would go and try to contribute a small fix/feat to sqlc to understand sqlc code structure and from there potentially a bigger feature/extension for sqlc.
Also, It'd be nice to know what the transfer protocol is like. What format is used to transfer between a Source and Destination?
There are no connectors for AWS, GCP, Azure in FiveTran, Airbyte, Meltano but as we extend the number of our source plugins I believe this question will come up more and we will add those products as well to our comparison list.
The protocol is just standard/plain gRPC (https://www.cloudquery.io/docs/developers/architecture). Protobuf is defined here - https://github.com/cloudquery/plugin-sdk/tree/main/internal/...
Basically just the normalized, verified data + metadata, types
Honestly the language is the new JS and just another one to remind us how miserable software can be with half baked enterprizy solutions to just get the job done faster.
