21–30 of 94 posts
> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggregating stuff in a regular HTTP API, but it does seem to give a better developer experience on the frontend. At a certain scale, I think it could be worth the investment, but I don't think it really lives up to the hype.
Rarely. Assuming the GraphQL server is using REST endpoints behind the scenes, i'm yet to find a request waterfall that required manual rather than automatic optimizations. I'm assuming there are cases where a manual path is faster, but they're less common that you'd think.
Maybe the recent wave of JS framework had at least this beneficial side effect.
> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
My question is then: - will there be a "standard" way to describe the data model (aka vocabulary) of your GraphQL endpoint? Something like RDFS or OWL.
Anyone got experience transitioning a large production site from REST to GraphQL? I'm aware Yelp did this recently, wondering about any pain points. In particular, I have some FUD about how to go about rate limiting, when in theory a single request could grab every resource that the client is authorized to retrieve, and thrash the database. Looks like Github counts/restricts the number of total nodes returned: https:…
> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
Until then, what you gain is "only" a completely decoupled backend that will accommodate frontend developers work in exchange for more generic logic in the backend. Not necessarily a bad thing, if this is how your shop works.
> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
But you have to do it manually. GraphQL removes that pain (or at least that's my understanding:.
But there's still going to be a decent bit of backend tuning which in my experience is the hard part (unless the organization is so dysfunctional new API version design meetings descend into a hostage exchange).