REST without a IDL language with a schema definition is But things like OpenAPI =GraphQL has some disadvantages thought, due to the graph setup.
REST vs. GraphQL – A search for evidence on which is better
191–200 of 243 posts
Re: REST vs. GraphQL – A search for evidence on which is better
#192Earlier quoted context omitted.
Maybe, but is it really a good idea to rely on the laziness of developers and hope they give you feedback? I've not seen this work out well so far.
To my mind, a system architecture that does not take into account is the flawed one, not the other way around.
*does not take human nature into account
Re: REST vs. GraphQL – A search for evidence on which is better
#193There is some kind of toast on this site that never goes away telling me all kinds of info I care nothing about (new member, so and so bookmarked this etc). I would like to fallaciously suggest that only a site with such poor judgement would host papers such as this that come to such erroneous conclusions
It is extremely distracting from the main content too. Whoever though this idea was good, needs to re-evaluate their decisions.
Re: REST vs. GraphQL – A search for evidence on which is better
#194As someone who has heavily used both REST and GraphQL in the past and actively, I find this comparison heavily similar to using raw HTML versus React. When it really boils down, GraphQL is just REST with types and the capability of performing multiple requests in one. Much like React is a way of creating component types from HTML elements. GraphQL takes a bit more work to get setup and running, but it's soo worth it…
What are the tradeoffs for doing so and what makes them more compelling? What applications don't benefit as much by using GraphQL?
Re: REST vs. GraphQL – A search for evidence on which is better
#195Earlier quoted context omitted.
It doesn't lose it - it just doesn't remain an advantage over the alternative. It's not like if there is a schema with a REST API, the GraphQL alternative becomes un-typed.
FWIW, the types possible to express in gql is quite a lot weaker than the ones in openapi, where you can for example say not only is a field a string, but also that it matches a certain format.
You can create custom scalars in GraphQL, which then have shared logic for serialization on the backend and frontend. That knowledge on format does have to be sort of out-of-band but that could probably be added to the standard.
Re: REST vs. GraphQL – A search for evidence on which is better
#196Earlier quoted context omitted.
I think you misunderstand. You can write very restricted queries that mirror REST routes 1:1. No need for persisted queries. Persisted queries enter the game when you define a query that potentially can become very complex and deep and then want to restrict the complexity in specific ways. But that is not required if you just want to mirror a RESTful API.
> I think you misunderstand. I don't > You can write very restricted queries that mirror REST routes 1:1. No need for persisted queries. What stops a frontend developer writing an ad-hoc query? > Persisted queries enter the game when you define a query that potentially can become very complex and deep That... That is exactly what I wrote. --- Honestly, I'm baffled at GraphQL defenders. It's like they never even read…
[deleted]
Re: REST vs. GraphQL – A search for evidence on which is better
#197Earlier quoted context omitted.
Maybe, but is it really a good idea to rely on the laziness of developers and hope they give you feedback? I've not seen this work out well so far.
To my mind, a system architecture that does not take into account is the flawed one, not the other way around.
Taking into account is one thing, but relying on lazyness... I don't know, I'm not convinced
Re: REST vs. GraphQL – A search for evidence on which is better
#198My problem with graphql always comes down to permissions and performance.
I feel like we went through the thought process of: okay, front ends are smart enough to ask for the data that they want, so why not just let them structure their own queries? But my problem is, the only time a client is smart and and to just ask for whatever they want us if I'm building an admin application, otherwise, all sorts of access control needs to be added to various levels of most queries, something I've never felt as though GraphQL handles well.
Then there's the performance stuff, hitting caches or doing joins, it's much harder to make a GraphQL backend know when it can do these things, short of simple cache lookups by very limited keys.
With REST, I'm somewhere in the middle. I'm saying, okay, these are the resources, and these are the actions. You might get a little more or a little less data than you wanted with your response, but I know exactly what you're getting, can optimize it, and test the shit out of it.
I'm by no means resistant to new technology, I have just never worked on a project that avoided these pitfalls.
Re: REST vs. GraphQL – A search for evidence on which is better
#199Think about an API like a control panel for a machine. It is precisely designed for an operator abstracting away the details of the machine's electrical schematic and every component. It is user focused . GraphQL is like opening up the entire machine, stripping off the panels and working on live circuits. IMO GraphQL is great to quickly develop something. If your front-end is making 18 queries to REST API and you're…
> IMO GraphQL is great to quickly develop something. If your front-end is making 18 queries to REST API and you're making a case for how awesome GraphQL is, I think perhaps your REST API design needs to be properly thought out. I personally like to start with GraphQL, once everything is ready and I know what I want, write proper API endpoints. They can be REST-ful or REST-less. One API call for one function the front-end needs to perform.
I think a good way of doing this is to use Postgraphile/Hasura to make a quick and easy GQL API, and then when you move to your "proper API endpoints", you can use Postgraphile in schema-only mode [0] at first, and then you have the ability to arbitrarily change endpoints to use custom SQL queries instead of using Postgraphile to build your query, while leaving other, simpler endpoints to still use Postgraphile.
Re: REST vs. GraphQL – A search for evidence on which is better
#200I think this paper misses the point. If you're a front-end developer, if you have a robust graphql endpoint available to you it's unbelievably amazing and productive. But providing a robust graphql endpoint that is performant, scalable, secure, etc, is much more difficult than REST. GraphQL is optimizing for a different set of developers, and this paper only studied one group.
Good points. I had to make the GraphQL vs REST (vs maybe grpc) decision a while ago, but for my application, the API consumers are either myself (I also do the front-end) or our customers, who are not likely to be very technically proficient - for which a REST API is probably the most accessible.
Just need to figure out server-side validation now.