graphweaver

Thanks this is what we have on filters so far:

https://graphweaver.com/docs/filters-and-operators

The aggregates package looks very interesting, we would love to see something similar for Graphweaver.

We appreciate all the hard work that Hasura has done to make GraphQL a main stream technology.

Here are some links around security:

https://graphweaver.com/docs/adding-local-authentication

https://graphweaver.com/docs/implementing-authorization

https://graphweaver.com/docs/column-level-security

We have deployed Graphweaver using serverless and lambda be interesting to see how we could convert it to multi-tenant.

We have done performance testing when releasing client projects but nothing that directly compares Graphweaver to competitors.

I will add this to the list for us to do.

Great can you point me to the filtering/grouping capabilities? I will take a look.

We actually do that with the Contentful integration we’ve built. It dynamically reads the schema then creates the API.

Not everyone will see TS as an advantage but there are many who will.

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.

We add validation using https://github.com/typestack/class-validator.

I will make sure we get this documented.

We have used postgres with every client deployment so far, it's our go to relational db.

We have also needed to connect to a 2nd or 3rd data source on every project. So the power is when you combine these data sources.

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:

https://dev.to/tnodell/exploring-the-benefits-of-graphql-cod...

The main difference is Graphweaver is code-only approach with Typescript. GraphQL Mesh is a schema-first approach.

Both great projects, different philosophies.

Yeah it is comparable:

- 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)

You're right we need to improve the documentation on this. We do have an example though:

https://github.com/exogee-technology/graphweaver/tree/main/s...

We have also added the OpenAPI spec on the roadmap however, every REST API we have integrated so far has been custom.

The REST connector allows you to have full-control over how it connects to the API:

https://github.com/exogee-technology/graphweaver/blob/main/s...

Nothing out-of-the-box for this yet. We have actually done this for our clients, but it has been a custom field resolver:

https://graphweaver.com/docs/graphql-entities-and-resolvers#...

Thanks for all your hard work skeep!

We agree, with any GraphQL API you need to make sure it is hardened for production.

We are looking to add more on documentation on this soon and maybe a tutorial series on exactly this.

We have some docs on that here:

https://graphweaver.com/docs/implementing-authorization

The auth is at the access control is at the API layer.

This is true but like with any build there are many decisions to make. We have settled on this stack for our API's and we think others will find it useful.