[mdjahidhasan]

Your experience with massive-scale GraphQL usage is valuable. Tailcall's approach to API composition is intriguing. Can you share specific scenarios where Tailcall has proven to be particularly effective in comparison to other GraphQL solutions?

[tusharmath]

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.