Ako Suminoe :njp: on Nostr: Not my team. They are 3rd party API services. The tradeoff is between ingesting one ...
Not my team. They are 3rd party API services.
The tradeoff is between ingesting one query that has a lot of load on the backend and a bunch of queries that each have a smaller load but combined have a greater one. If a query takes too long, the smarter thing to do is to push it into a background job and give the caller a URL to fetch the result later. I don't know if common GQL tooling supports this, but this is the proper solution.
And no, it's not the same as handing out unrestricted access to your DB any more than REST is. It's an alternative way to make APIs, not a SQL replacement.
Edit: GQL also helps resolve the "problem" of corporate silos, even if it wasn't relevant to my specific case. It is a serious issue, and reducing the need for communication between different teams that are in different stages of the SDLC is a very good thing.
The tradeoff is between ingesting one query that has a lot of load on the backend and a bunch of queries that each have a smaller load but combined have a greater one. If a query takes too long, the smarter thing to do is to push it into a background job and give the caller a URL to fetch the result later. I don't know if common GQL tooling supports this, but this is the proper solution.
And no, it's not the same as handing out unrestricted access to your DB any more than REST is. It's an alternative way to make APIs, not a SQL replacement.
Edit: GQL also helps resolve the "problem" of corporate silos, even if it wasn't relevant to my specific case. It is a serious issue, and reducing the need for communication between different teams that are in different stages of the SDLC is a very good thing.