Yeah sorry will address it directly. Graphweaver is different in a number of ways:
- Graphweaver is not just Postgres, you can run it connected to only MySQL
- Graphweaver can connect to one or more datasources. You can even connect both MySQL and Postgres together. Sounds crazy but could be good for a migration.
- Graphweaver has two layers the API layer and the Data layer. Both of these are represented by coding classes in Typescript. You have full control over how these are exposed and defined in the entity files.
- Graphweaver does not automatically reflect the database. Instead you run an import command in our CLI tool that creates Typescript class files for your database. From there you can edit them as needed.
Nice, interesting approach. I like Mikro ORM, I was thinking about building on top of it recently, I think it's a good idea.
Looks like you went for the ORM equivalent of the Shadcn/ui approach. "We generate your code so you can customize it" instead of the more traditional "You use a library and can provide options to it to customize it". I like it!
Postgraphile has a bunch of very cool filtering/grouping capabilities (with plugins), would be nice to have that at some point
With Wundergraph, you define schema first. This generates types and hooks that you can then use on the front end. The production API is not a GraphQL API its Rest I believe.
Graphweaver also generate types and react hooks for the front end, when running `graphweaver watch`. But Graphweaver is a GraphQL API and that is deployed into production. We wrap GraphQL Codegen and also do our own datasource introspection. More on that in this article:
- We are 100% open source.
- Written in Typescript.
- We support any data source directly in the server process, either with pre-built data providers or build your own.
- We support cross data source filtering (get orders from database with CRM username)
I will add this to the list for us to do.