graphql-query-complexity VS crystal

https://github.com/slicknode/graphql-query-complexity

In addition you could introduce CI tools to enforce your devs stop writing such complex queries. Also see the @skip and @include directives that can further be used to control what data is queried. In practice, however, this isn't something that comes up too much. In cases where I have seen this happen, it's usually because a developer is trying to reuse fragments without considering what data they are querying, and whether they should be reusing those fragments.

https://graphql.org/learn/queries/#fragments

very cool! I was looking at https://github.com/slicknode/graphql-query-complexity

There are a couple of techniques that can be used to prevent this kind of problem one of them is GraphQL Query Complexity Analysis which is, as the name suggests, very complex to implement correctly. It requires analysis of how the graphql API is used, and what queries and mutations are most often called. If you get this wrong, there is a danger of the server denying perfectly valid queries.

The problem is that those queries are not prevented by commonly available rate limiters. You can send a single request to a GraphQL server that completely overwhelms the servers. To prevent such queries to GraphQL APIs, I wrote graphql-query-complexity, an extensible open-source library that detects such queries and rejects pathological queries before consuming too many resources on the server. You can assign each field a complexity value, and queries that exceed a threshold will be rejected. In Slicknode this protection is added automatically based on the number of nodes that are being returned.

I didn't see a v5 tag in order to know, and I have no idea what "utils/graphile" does for the project, but one will want to ensure they are aware of its licensing scheme https://github.com/graphile/crystal/blob/db8894c74eb0ec3fe96...

I was about to say “but this one is!” and realized I had confused PostgREST with PostGraphile. If you’re interested in GraphQL, you can check out PostGraphile here: https://github.com/graphile/postgraphile

If you point is to abstract all the CRUD/GraphQL application, Go isn’t needed. You can go with PostgREST or Postgraphile.

What do you mean locally? Hasura is OSS, and you can run it locally (you have autogenerated SQL statements) Here you can just use Nhost and its CLI;

Alternatives are https://github.com/graphile/postgraphile or dgraph as you mentioned. Hasura is working on support for sqlite, so you may have some blockers there, you can also look into the Prisma engine which has GQL as an intermediate (for resolvers, for example)

I've personally found Postgraphile to be fantastic. Nicer to use than Hasura and fully OSS: https://github.com/graphile/postgraphile/

Hi all, this sounds very cool. How does pg_graphql compare to Postgraphile? https://github.com/graphile/postgraphile (besides I guess running in the DB with PLpgSQL instead of as a NodeJS server)

Did you think about integrating Postgraphile with the Supabase ecosystem or have specific limitations with it?

Thanks!