GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them. At the same time I can see that it works in the other way around; back-end engineers don't ha…
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API
GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them. At the same time I can see that it works in the other way around; back-end engineers don't ha…
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change
Is this "adding of metrics" to fields part of graphql api, or something the data store would provide? Apologies but I've only just started exploring graphql.
Well, we could use SQL instead of GraphQL and would get much more freedom on the requests we could make. I supose that this was the idea of nicoJuicy.
The problem with that is it assumes that there's no logic on the back end, outside the database, that transforms data before sending it to the client. If all you want is a way to submit SQL queries from a front end to a SQL database, you could just have the front end talk directly to the database. There's no need for a back end app in that case. But APIs are for talking to applications.
It also assumes all of the data is in one database. A common use case for GraphQL is to wrap multiple REST APIs and proxy calls to them as a "master API".
So, why not just use StructuredQL? Seriously, we have DB user roles for access control, and most database traffic from web or app dashboard clients is read based anyway.
GraphQL is a way of exposing an API
It is not a direct interface to the database backend
DB user roles for access control won't help much if you had the credentials to your db stored in javascript source so that the web front end can query your postrges db directly
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change
Is this "adding of metrics" to fields part of graphql api, or something the data store would provide? Apologies but I've only just started exploring graphql.
No, not part of graphql. Apollo Optics (no relation) is an option, or you can instrument the fields yourself just like you would implement any other instrumentation.
GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them. At the same time I can see that it works in the other way around; back-end engineers don't ha…
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API That can be easier since you can add metrics to each individual field rather than url, allowing you to deprecate rarely used fields knowing what you'll break and alert only those who are using it of the change
That could be true, but field would not be enough, at least in my limited understanding. I can imagine that I'd also want to know which information is retrieved through other pieces of information. So lets say `Post -> Comments -> Author -> Avatar`, rather than just `Avatar`. This is important because it shows that whatever I do I should at least support the relation to `Avatar` through `Post -> Comments -> Author`.
GraphQL so far to me just seems like a way to facilitate freedom to front-end engineering in terms of not begin dependent on the back-end when query-ing; I image that when back- and front-end teams are separate that it can be frustrating to front-enders to wait for the api developers to have made something available to them. At the same time I can see that it works in the other way around; back-end engineers don't ha…
> with GraphQL there are relations that get used through each other which is less straightforward to determine when pruning or updating your API Add a new GraphQL version endpoint?
In an ideal world API versions would spawn feature-complete from version to version and older versions would require 0% maintenance, yes, but this is not how the world works.
As I said, it could work this way for Github, but not your relatively small SaaS. My point was that investing in these kinds of things might not be for everyone.
So, why not just use StructuredQL? Seriously, we have DB user roles for access control, and most database traffic from web or app dashboard clients is read based anyway.
GraphQL is a way of exposing an API It is not a direct interface to the database backend DB user roles for access control won't help much if you had the credentials to your db stored in javascript source so that the web front end can query your postrges db directly
Passwords in your javascript app is a crazy idea - the user goes through auth anyway, why not store their credentials there?