We've conducted benchmarks across various GraphQL backends and discovered that Hasura is performing significantly slower than its counterparts. We want to ensure the accuracy of these results and are eager to collaborate with Hasura experts to explore potential improvements. Could we discuss strategies to optimize Hasura's performance in our benchmarks? Looking forward to your expert insights.
P.S.: Please focus on the constructive aspects of these benchmarks, as they specifically test a feature present in Hasura, which is marketed to deliver "fast" GraphQL APIs on top of any data source.
With Tailcall, you could compose API over multiple any of the following formats REST, GraphQL, and GRPC APIs to create a unified API endpoint. This could also be any of the above. So you could expose a set of REST endpoints atop, multiple GRPC APIs, where you are not just doing basic translations, but also sophisticated data transformation that has business logic inside it.
Tailcall is building something similar in that regard. The idea is to allow developers to specify their orchestration requirements using a DSL and then behind the scenes generate an ultra high performance backend for GraphQL. The query could span over REST, GRPC and other GraphQL services. Check it out — https://github.com/tailcallhq/tailcall
Yes, that is the best time to build a GraphQL API. It will save you many hours later. Like it or not, eventually if you are building a mobile app, you will move to GraphQL eventually. It's a massive pain to do it when you have everything running.
GraphQL will save you from embarrassing errors on the client and improve performance for sure. My recommendation is — Build API and expose them using REST or GRPC. Use a solution like https://tailcall.run/ to create a GraphQL facade on top of it for your clients to consume.
I am not sure if I understand what you by the "frontend server"? I think Tailcall is closer to AppSync than Amplify.
Second part of your question: You can define a set of "allowed headers" that will be automatically forwarded upstream. In your case, you can set the allowed headers to `Authorization`.
The idea of tailcall is to move the graphQL abstract closer to the client. So for example, if you are building a web application, you don't need to depend on the backend teams to build a GraphQL implementation for you.
You should be able to use the tailcall DSL and express your orchestration requirements using it. The DSL looks like a normal GraphQL file so there is no new language to learn. Because this file is for the client, it can be literally in the same repository as the client, effectively ensuring the GraphQL server and the client are always on the same version. A simple git ops is then implemented, to auto-deploy the orchestration logic and release the mobile application simultaneously.
Because you have a DSL to represent the orchestration logic, you can introspect how the orchestration would happen even before your server starts. So you can apply lint rules on the configuration, and also a ton of ahead-of-time optimizations. You can also identify n + 1 upfront, restrict them in certain cases, and allow for others.
Moreover, you don't need to think about the performance and maintenance of this service. Once deployed on your/our infra, every time there is a configuration change, we just perform a reload and within seconds it is updated across the infrastructure.
This is a fundamental shift from how graphQL is maintained traditionally. It gives backend engineers an opportunity to think in terms of orthogonal APIs or migrate from monolith to microservices etc. without worrying. Secondly, it gives frontend engineers the power to design the schema that makes sense for them, without writing any code or being on-call for any outages.
If you are a cranelift expert and have worked with compilers wasm using rust we have something that might interest you. Just send us your prior work with cranelift to jobs at tailcall.run and we will get in touch.
Tailcall is a no-code solution for writing GraphQL backends. It is heavily focussed on building a high-performance implementation that can make GraphQL practical for service to service communication. Tailcall does a lot of AOT optimizations to get performance that's practically very hard to achieve while writing code by hand. You will clearly see in the benchmarks above that it's only slower than static rust.
The configuration that is provided by the user, is text, however it's parsed into an AST, then converted into a low-level implementation called the blueprint. The hash is that of the blueprint and is free of any whitespaces or textual changes.