You want to provide API docs to your users? Good fucking luck. You want your product to be adopted, but if this fucking shit is in the way, which no one understands how to use, and can't be documented with standard OpenAPI v3 spec. Good fucking luck with your product gaining traction in the marketplace. Users want a standard REST API which is easy to understand and easy to document.
Ok hot shot, these three companies are using the current best in class GraphQL doc generator, GraphDoc. Take the GraphQL documentation from any of these three companies and produce something useful:
Compare with best in class REST API documentation based on OpenAPI 3.0 specs: https://developer.mixpanel.com/reference/raw-event-export
As a non graphql user the docs look fine. What am I missing?
Ok, produce a useful integration based on the docs.
3 weeks ago
Anonymous
>Compare with best in class REST API documentation based on OpenAPI 3.0 specs:
I seem to recall graphql also having a way to test queries. >Ok, produce a useful integration based on the docs.
I don't even know what these companies do
3 weeks ago
Anonymous
For testing queries, you're thinking of GraphiQl Playground which is bundled with most products that have a GraphQL API.
>this is a BRAINDEAD take
Apollo literally creates docs for you, the real issue is that retarded devs nest resolvers which makes everything slow as fuck
Most people who implement GraphQL use it to essentially expose the entire database. Shopify is a good example of that - you end up with half-page queries to do basic things. It's a big step backward from raw SQL which would be insane to use in such a fashion, and therefore literally fifty+ years behind normal API good practice.
>Most people who implement GraphQL use it to essentially expose the entire database
This.
I've used it. I've been asked to expose it, and I've integrated shit with it.
It's okay for read-only data, trying to mutate data and put it back is the stuff of nightmares. It's best "usecase" is when the person making the "API" does not give a shit about how it's going to be called, thereby letting webshitters roll their own requests.
In that same usecase, performance issues are likely, because your consumer does not give a shit how your database is modeled, but is now smacking it with whatever they want, and probably for way more data then they actually needed.
The whole thing is just a waste, unless your API has so many datapoints that you can't make reasonable endpoints for each of them. That specific case flies in the face of most domain modeling and service writing practices, so something is already fucked at the point.
tl;dr: It's another solution for a specific problem (1 service, with way too many data points), bluntly applied where it doesn't fit because it sounds trendy.
I literally do not want to learn anything new. I know how data structures work and I know how to make HTTP requests. I literally do not give a fuck about anything else.
nope, you just suck cock you homosexual retard
Ultrashit, the worst decision my company ever made was copying this Facebook bullshit. It continues to haunt us three years later.
What makes it shit? It looks extremely useful
You want to provide API docs to your users? Good fucking luck. You want your product to be adopted, but if this fucking shit is in the way, which no one understands how to use, and can't be documented with standard OpenAPI v3 spec. Good fucking luck with your product gaining traction in the marketplace. Users want a standard REST API which is easy to understand and easy to document.
So what you're saying is that it's yet another case of tech illiterate troglodytes standing in the way of progress?
More like a tech illiterate middle management troglodyte invented GraphQL and is pushing it on tech chads.
I’m not a graphql fanboy but this is an awful take by a retard who got filtered by the easiest API to consume, ever. Lmfao are you indian?
Ok hot shot, these three companies are using the current best in class GraphQL doc generator, GraphDoc. Take the GraphQL documentation from any of these three companies and produce something useful:
https://help.tableau.com/current/api/metadata_api/en-us/reference/
https://www.okteto.com/docs/api/schema/predefinedvariable.doc
https://documentation.extremenetworks.com/XIQ-SE_API/GraphQLschema/byte.doc.html
I'll wait.
As a non graphql user the docs look fine. What am I missing?
Compare with best in class REST API documentation based on OpenAPI 3.0 specs: https://developer.mixpanel.com/reference/raw-event-export
Ok, produce a useful integration based on the docs.
>Compare with best in class REST API documentation based on OpenAPI 3.0 specs:
I seem to recall graphql also having a way to test queries.
>Ok, produce a useful integration based on the docs.
I don't even know what these companies do
For testing queries, you're thinking of GraphiQl Playground which is bundled with most products that have a GraphQL API.
Example: https://cloud.hasura.io/public/graphiql?header=content-type:application/json&endpoint=https://api.graphql.jobs
And it's fucking useless without proper documentation which is impossible with GraphQL unlike standard REST APIs which have the OpenAPI 3 spec.
>filtered
you’re a brainlet and you’re throwing a tantrum.
Couldnt you just document what the structure fields are the same way you would for a rest api?
I assume because on the backend you need to figure out what to do to produce the requested values?
>this is a BRAINDEAD take
Apollo literally creates docs for you, the real issue is that retarded devs nest resolvers which makes everything slow as fuck
Very comfy for frontend, nightmare for backend
It's not shit, but the use cases where it actually makes sense is super limited. You must have REALLY complex data structures, to be worth the effort.
In my experience the only people attacking gql are complete idiots, so yeah makes sense you post here OP
It makes sense for a number of popular use cases like social media sites
For regular crud apps it's probably better to just use standard queries
Most people who implement GraphQL use it to essentially expose the entire database. Shopify is a good example of that - you end up with half-page queries to do basic things. It's a big step backward from raw SQL which would be insane to use in such a fashion, and therefore literally fifty+ years behind normal API good practice.
>Most people who implement GraphQL use it to essentially expose the entire database
This.
I've used it. I've been asked to expose it, and I've integrated shit with it.
It's okay for read-only data, trying to mutate data and put it back is the stuff of nightmares. It's best "usecase" is when the person making the "API" does not give a shit about how it's going to be called, thereby letting webshitters roll their own requests.
In that same usecase, performance issues are likely, because your consumer does not give a shit how your database is modeled, but is now smacking it with whatever they want, and probably for way more data then they actually needed.
The whole thing is just a waste, unless your API has so many datapoints that you can't make reasonable endpoints for each of them. That specific case flies in the face of most domain modeling and service writing practices, so something is already fucked at the point.
tl;dr: It's another solution for a specific problem (1 service, with way too many data points), bluntly applied where it doesn't fit because it sounds trendy.
I literally do not want to learn anything new. I know how data structures work and I know how to make HTTP requests. I literally do not give a fuck about anything else.