6 ms·

What are the downsides for using GraphQL over REST?

• tayo42 4y ago
  Can it be cached yet? I didn't think any http caches work with graphql?
  • subarctic 4y ago
    who caches their API though
    • BackBlast 4y ago
      I do. It helps with latency when someone hits the "back" button and your queries are page/view based. Instead of seeing the delay of the query, it's instant. Because, well, it probably should be. Cache times are usually short, < 5 minutes, and are cleared whenever a POST/DELETE/PUT are issued. Works pretty well in my experience.
      • subarctic 4y ago
        is this built-in browser caching? how do you set it up so it gets invalidated by POST/DELETE/PUT?
        • TylerE 4y ago
          You’d be surprised how far you can get with even the dumbest possible caching strategy. I’m talking about something like a server side memcache that just blows everything away on any non-log write. If your baseline is so a new fetch every single time anyway, it doesn’t take much to achieve some pretty impressive wins.
        • BackBlast 4y ago
          The API calls shouldn't be stored in the browser. That would just be a mess. A refresh should predictably fetch fresh data, because that matches user intent. There are also times I want to turn caching off. The understanding of what is reasonable to cache and what isn't is better understood on the front end, where the data is actually used/consumed. Browser caching is out for my use case. I create a JavaScript object that matches the interface of my request library, axios in my case. The cache is basically a middleware to it created by function wrapping. Kind of like how memoize works but with a bit of extra smarts. I have my own .get(), .post(), .delete() and .put() functions. So when a .get() is called, it's a cache check and return the stored value. If not found call axios.get() with the passed in args and store in cache before returning. The post() function clears the cache then passes through the arguments to axios.post(). Etc. The 5 minutes is accomplished with an entry on the event loop to remove said item. It's only like 30 lines of code. The real wins for this is in basic navigation. Clicking around site exploring, makes it snappy. Another advantage is lowering the total request count a bit to the backend, lowering the cloud bill.
  • plagiarist 4y ago
    I believe requests are usually a POST, so HTTP caches must ignore it to work properly. I imagine there are caches that understand GraphQL which could be used.
  • BackBlast 4y ago
    Last time I used GraphQL seriously, caching was suppose to work. I never really saw it work well. Not like you can predictably cache REST.
  • nforgerit 4y ago
    The GraphQL clients I've seen normalize GraphQL responses and cache them in the client, i.e. browser cache, IndexedDB or whatever native App ecosystem you're using. They usually work as read-through cache but depending on the App, this might not be the right strategy.
• chrisco255 4y ago
  One downside is that depending on how your backend is structured, nested GraphQL queries can hit an arbitrary number of different endpoints, tables, services, or databases behind the scenes. And some of those queries could take a long time to resolve and not cache as cleanly as individual endpoints.
  • pyrolistical 4y ago
    Also the lazy approach that nobody should ever do but we know everybody does at some point of connecting it directly to databases will leak data
  • threatofrain 4y ago
    But if you needed data from so many resources, don't you need to hit them up one way or another?
    • chrisco255 4y ago
      Possibly. As mentioned, it's very easy to cache individual endpoints both locally on the client and on the server side with REST. Since GraphQL is so flexible, it doesn't make caching responses very easy. It's a trade-off.
• afavour 4y ago
  Extra client dependencies, for one. REST support is baked into pretty much every web browser and OS. But for GraphQL I’ve seen some hideous deployments with dependencies on giant libraries as well as bundles containing dozens of GraphQL queries as long strings, jacking up the memory usage of the webapp.
  • thexumaker 4y ago
    Coming from a saas API startup using REST for everything to a more internal product facing company using Apollo graphql for its core services is weird. On one hand it’s a lot more flexible to return whatever you need on the frontend but on the other hand you get some really heated queries and if you don’t map out your objects correctly you get lots of queries that don’t objectively make sense in what the return. You also just get devs adding new queries for stuff that probably shouldn’t be for the resource they used
• ChicagoDave 4y ago
  Dependency issues will worsen over time. You’re just building a monolith with it. API interfaces should be dumb and simple. Neither REST (Swagger rules) or GraphQL are healthy long-term implementations.
  • za3faran 4y ago
    Genuine question: what are healthy long term implementations? gRPC?
    • ChicagoDave 4y ago
      UI needs data which can be represented in a read model. Read models can be represented however the receiver needs it. UI’s should rarely need to make complex or large queries. So if I’m displaying data for one subject (customer) I should have a read model that delivers everything I need to display. If I need an Orders or Inventory read model, that’s fine. Sending data to an api for creation or updating should be simple business commands and not based on resources or transport. My mantra is to think like the business, not like an API or data store.
• BackBlast 4y ago
  Complexity of the backend is much higher with GraphQL. Caching is much more difficult (not impossible) compared to REST. The client query system is bigger and more complex. So... Complexity generally is higher with GraphQL. Some data flows end up with dependencies you don't know when you build a query. Such as a auth token, credentials, etc. So you end up with several round trips anyway for these cases. A lot of the advantages to GraphQL don't materialize due to how front ends are built. It encourages the use of a global store to shove all data into from the large query you just completed. Except every front end I've ever worked on that used GraphQL basically used it just like REST with a few extra features because typical front end architecture encourages this. Taking little advantage of what GraphQL is suppose to offer. In my experience versioning was more painful with GraphQL than it was with REST. With REST you know you just need to rev the path or some other obvious marker like a header, which allows you to run both versions side by side. In GraphQL this isn't so obvious that you need to do the same kind of separation for braking changes. And breaking changes are occasionally needed contrary to what some people believe. So when I make a backend now, it's vanilla REST without anything fancy. I favor simplicity.
• AdrienPoupa 4y ago
  Backend complexity as mentioned above, as well as potential performance issues. You really want to avoid N+1 issues by batching all the fields and relationships you want to query at once. It's too easy to realize you're running n queries for each field of every entity you are retrieving...
• wildpeaks 4y ago
  In short, it burns through your runway faster because it's more complex and expensive (to setup, maintain and host).