[deleted]
GraphQL vs. REST APIs: a complete guide
11–20 of 103 posts
Re: GraphQL vs. REST APIs: a complete guide
#12GraphQL is extremely useful, if only to have strong type validation between disparate languages, via code generation. It can be a universal typed schema of your data against which you can use whatever server and client combo you want. It's like tRPC but you're not forced to use only TypeScript.
I also have to plug this video [0], since many people think GraphQL somehow is a competitor to SQL and that it goes between the server and the database; it does not and has not ever been intended to be a replacement for a database query language and in fact should never be used there at all. It is only for client/server communication, not server/database communication.
Re: GraphQL vs. REST APIs: a complete guide
#13[deleted]
Re: GraphQL vs. REST APIs: a complete guide
#14I really hate these bland, barely actionable advices with no examples, created for SEO purposes.
Nobody knows how to measure the "complexity" and "evolvability" of the API and where exactly is the threshold that justifies going from REST to GraphQL.
So here's my opinionated alternative:
Use REST everywhere, unless you can justify the exception.
A good exception is when you don't know the audience and use cases for your API. E.g. if you have hundreds of different apps using the same API and you have no idea how they are going to use it. You know who does it? Facebook.
If you're just dogfooding an API for your website, you don't need GraphQL. If you need one service to talk to another, you don't need GraphQL.
Re: GraphQL vs. REST APIs: a complete guide
#15REST is basically a subset of GraphQL.
Re: GraphQL vs. REST APIs: a complete guide
#16REST is basically a subset of GraphQL.
From a caching perspective REST is a superset IMHO.
Re: GraphQL vs. REST APIs: a complete guide
#17I like GraphQL because it allows me to describe my API like a domain rather than just a collection of resources. REST is difficult to map to a true domain model because domains aren't just collections of resources. They have nuance. And with GraphQL your API matches your domain, so there's no limit to what your application can accomplish. For example, adding another feature to your front-end no longer requires going back to your API to add a tailored endpoint nearly as often. At worst you're adding a property somewhere that is now available to all your use cases. GraphQL embraces mutations in a way that REST frankly can't without being glorified RPC, and it doesn't have the same perverse incentives such as re-using an endpoint because it exists even though it may be suboptimal.
So, in my opinion, unless your application is very resource/entity-intensive (and you don't mind a little RPC-style bloat) then GraphQL is often a better choice than REST. And if you actually have a rich domain to model (this is the case even for many small applications), then GraphQL is often a better choice than RPC.
Re: GraphQL vs. REST APIs: a complete guide
#18Here's how you do it: - REST/Hypermedia when you're actually building a website (not app) and your "site" is a state machine - OpenAPI when you expose and API to 3rd parties - Isomorphic TypeScript APIs when you're using TS on both backend and frontend [0] - GraphQL when the frontend needs to talk to an API layer provided by different teams - OpenAPI when one backend talks to another backend - gRPC might be an option…
One thing Id suggest - "gRPC might be an option but most teams dont need it" - needs a revisit. As a backend-dev (who does front end when needed - and that too by slapping NextJS on an API) I have found starting from a grpc set of services and generating http/openapi specs from it to be much for maintainable and understandable than starting with the OpenAPI spec and working "inwards". Apart from a (mostly) single source of truth for my interface intent - I also get a system that is amenable to scalability concerns than most of the time when I started working inwards. I might be in the minority as most folks who build services come from a product background?
Re: GraphQL vs. REST APIs: a complete guide
#19I like GraphQL because it allows me to describe my API like a domain rather than just a collection of resources. REST is difficult to map to a true domain model because domains aren't just collections of resources. They have nuance. And with GraphQL your API matches your domain, so there's no limit to what your application can accomplish. For example, adding another feature to your front-end no longer requires going…
I love graphql. It allowed me to scrape a whole bunch of websites with almost no changes to my scraper.
Re: GraphQL vs. REST APIs: a complete guide
#20Here's how you do it: - REST/Hypermedia when you're actually building a website (not app) and your "site" is a state machine - OpenAPI when you expose and API to 3rd parties - Isomorphic TypeScript APIs when you're using TS on both backend and frontend [0] - GraphQL when the frontend needs to talk to an API layer provided by different teams - OpenAPI when one backend talks to another backend - gRPC might be an option…
Why does OpenAPI appear to be an alternative to REST in your list?