graphql-jit VS Hasura

In the end like all performance questions you'll have to measure it. Persisted queries, and even more extreme approaches, like a GraphQL JIT (https://github.com/zalando-incubator/graphql-jit) can remove a lot of the overhead.

We faced something similar. To improve GraphQL performance, we use graphql-jit. We turned off all other tracing that datadog turns on by default. Then, we then wrote a custom tracer to connect graphql-jit to dd-trace. Hopefully this same pattern works for you!

GraphQL JIT – GraphQL execution using a JIT compiler\ (0 comments)

https://github.com/zalando-incubator/graphql-jit#compile-a-q...

so I guess the difference is instead of having totally generic functions that parse the query every time, instead you can call a factory function up front to get a specialised function for a particular query

and V8 JIT can make that faster

JS has always been special & excellent because it allows multiphase programming. That one coild just add more code has been unique versus the world of statuc languages, where maybe youcd have some tool to generate stubs for Thrift or gRPC, then compule that in to your program. Which works ok, if and only if you know ahead of time what schemas you might need. Im these cases, you have to give up on stub code & start using more interprtted systems.

The advantages in js have been colossal, often an easy order of magnitude win to compile selectors & queries & other fast inner loop bits into jit compiled code versus having userland interpretters. Some of thd rete engines enjoy this. Just today there's graphql-jit. https://github.com/zalando-incubator/graphql-jit/blob/main/s...

Everything you say is full of doubt & scorn & skepticism. I just cant imagine living im such a world where each system had to know fully well ahead of time each type of data it might want to interact with, might have to have that precompiled & baked in. Thatcs a shitty miserable world that looks like the hell JS plucked us out of, by being a flexible, dynamic language that could load in routines & change it's behavior over time. Screw that dark hell world.

By using useParserCache we make sure to parse every unique operation only once. By using useValidationCache we make sure to validate every unique operation only once. By using useGraphQLJit we replace the default execute function with a just-in-time implementation.

One thing to understand is that, if you are using Node.js graphql-js would typically be the underlying implementation of all libraries and ultimately everything would get converted to JS/TS objects typically an AST ultimately making all these as abstractions on top of the existing way to define schemas. Note that the implementation can differ a bit in other languages or even within Node.js if you are using other ways of implementation like graphql-jit

Could you provide more context? the GraphQLJit plugin is a lightweight wrapper around graphql-jit. Could you share your previous datadog/graphql setup? Would love to dig in and find a proper solution!

Customizable runtime. Use custom GraphQL implementation such as graphql-jit or rolling our own for performance and cutting-edge features.

[4] https://github.com/hasura/graphql-engine/blob/master/architecture/live-queries.md

Another strategy is to model access control declaratively and enforce it in the application layer. ZenStack (built above Prisma ORM) and Hasura are good examples of this approach. The following code shows how access policies are defined with ZenStack and how a secured CRUD API can be derived automatically.

Today, this ecosystem is going strong with new providers like Hasura, AppWrite and Supabase powering millions of projects. There are a few reasons people choose this style of hosting, especially if they are more comfortable with frontend development. BaaS lets them set up a database in a secure way, expose some business logic on top of the data, and connect via a dev-friendly SDK from their app or website code to save data easily. These modern tools build a blend of managed database with curated plugins such as authentication, great admin dashboards, and function as a service type capability - all in one package, and often offered as a integrated hosted service.

Hi! If you’ve ever thought about something like using GraphQL for something like this.. You might like Hasura. (Obligatory I work for Hasura)

We’ve got an OpenAPI import and you can setup cron-jobs or one-off jobs and do things like load in headers from the environment variables to pass through. There isn’t currently an easy journey for chaining multiple calls together without writing any code at all, but you can wrap pretty much any API endpoint via OpenAPI import or a custom action, and you can even make minor edits to things like the API contract format to change aliases/naming.

Our goal is to join all the things, databases and API’s. Most people know us for instant GraphQL API’s that give you CRUD on your database, but we also wrap APIs.

Not sure if something like this would fit your use-case and do check out some of the other things mentioned, but depending what you are trying to do I think Hasura might potentially work.

You can find out more here: https://hasura.io

Nested Mutation - 113 thumbs up, and still open since 2019... another case of not listening to the users?

Hasura is an open-source real-time GraphQL API server with a strong authorization layer on your database. You can subscribe to database events via webhooks. It can combine multiple API servers into one unified graphQL API. Hasura is a great tool to build any CRUD GraphQL API. Hasura does not have any authentication mechanisms; e.g., you need an auth server to handle sign-up and sign-in.

7. Hasura