28 ms·

Why not use GraphQL?

• mirekrusin 6y ago
  We use jsonrpc 2.0 over websockets, typescript + runtime type assertions using functional combinators at the i/o boundary, it's very fast, bi-directional, type safe, pleasure to work with, easy to optimise (rpc call duration is easily captured), we know exactly the number of connected clients, it's easy to inspect outgoing buffer sizes, debounce notifications to do adaptive "throtthling" for people on slower networks etc. Above all, whole communication is uncomplicated and straight forward, lightweight. We tend to maintain client library by b/e team (maybe ~90% of code by b/e devs) for anything non trivial. The best documentation you can get is typed + jsdoc described library that you can just use. It is up to date. It's cheap to add new calls and notifications, it's easy to change apis where typescript guides you through changes required etc.
  • jensneuse 6y ago
    This is more or less the approach I'm taking with WunderGraph. There's just one exception. I'm not using websockets but simply a HTTP2 stream. Browsers have limitations regarding how many tcp connections you can open to the same origin and for each tab/window and websocket connection you have to open a new tcp connection. HTTP2 on the other hand can pipeline, depending on your browser, up to 200 streams over a single tcp connection, regardless of the tab or window. I've written a post on the topic: https://wundergraph.com/blog/deprecate_graphql_subscriptions_over_websockets https://wundergraph.com/blog/deprecate_graphql_subscriptions...
    • mirekrusin 6y ago
      Internet says: "(...) The infamous 6 connections per host limit does not apply to WebSockets. Instead a far bigger limit holds (255 in Chrome and 200 in Firefox). (...)". We do single connection per session (tab/window), there's no need to have more.
  • christophilus 6y ago
    Did you roll your own stack, or use an off the shelf toolkit? I’ve got something similar I’m wiring up right now in my project.
    • mirekrusin 6y ago
      We rolled our own.
  • draw_down 6y ago
    Super interesting approach, thanks for posting.
• k__ 6y ago
  There are simple reasons GraphQL is prefered to REST. It's a spec and not a architectural approach, which makes all GraphQL APIs more uniform than all REST APIs. It comes with a type-system that makes code generation really easy and allows for tools like Graphiql, which are orders of magnitude better than what most REST docs deliver. Can this be done with REST? Sure, just use something like OpenAPI. Problem is, most REST APIs don't use such tools/specs, but most GraphQL APIs do.
• nojvek 6y ago
  From my experience (most with github’s graphql api), graphql is phenomenal for get queries as you can get a big chunk of things in a single request exactly as you want. Github’s graphiql explorer was a joy to use and has saved me hours. For fetching a graph of nested data, graphql absolutely shines giving you fast responses of only the data you need. For mutations though, graphql is a giant pain in the ass. We wrote a bunch of things using graphql mutations and after two months reverted all mutation code back to using REST api. GitHub was flakey, some things didn’t have error responses. Mutations would screw up encoding “ character and it was just painful. REST api was much more deterministic and easier to work with. POST/PATCH/PUT/DELETE map well. I wish graphql didn’t invent its own quirky language and stuck to good ol json. In my experience graphql wasn’t worth the hype. There is a lot of over complication. We’ve got a lot more production success sticking to the basics. NOTE: we were interfacing with github’s graphql api from python. Outside of js, graphql tooling is sparse and sometimes non-existent.
  • jensneuse 6y ago
    Do you have ideas on how we can make mutations work better? What's missing? What could have helped in your situation? Would really appreciate your input.
  • Hurtak 6y ago
    > GitHub was flakey, some things didn’t have error responses That just seems like API problem rather than GraphQL problem. The equivalent would be REST API that just returns 500 without any additional info. You can be lazy in both stacks, I don't think any one of them particularly prevents you from being lazy about handling errors / typing useful error messages. > Mutations would screw up encoding “ character and it was just painful. Interesting, haven't heard about this. Also cant come up with how this is related to GraphQL, as you are just transferring string, just like you would do with REST. It seems more of an problem with some proxy/grapql framework layer that didn't handle the character correctly? > REST api was much more deterministic and easier to work with. POST/PATCH/PUT/DELETE map well. I don't see this as a big win, in GraphQL you just have `somethindUpdate` `somethingCreate` `somethingDelete` mutations, it is true that it is up to you to keep the naming consistent but nothing really that would be big trouble, or win for the REST. > I wish graphql didn’t invent its own quirky language and stuck to good ol json. If they did that you would end up with some quirky JSON query and schema syntax that would look like json schema or the mongo query schema. It is true that if you do new syntax you lose some json tooling that could be used (eg syntax highlight) but I don't see that much stuff transferable to the problems that GraphQL is solving.. so you would still end up with bunch of custom tooling on top, and when you need that you might as well go the way they did, with new syntax, that is not as quirky as whatever mongo/json schema like thing they would come up with. > There is a lot of over complication. This is definitely true and one of the most overlooked things by GraphQL evangelists, the "additional complexity layers" are non negligible.
• cs-szazz 6y ago
  There's something I never quite understood about GraphQL, and this seems like a good thread to ask! With REST, all my APIs are defined and I can easily test all the database queries my server will run, check that they're indexed, etc. But with GraphQL, my understanding is a client might be able to request something like "Give me all users whose phone number starts with 555". It's possible that query isn't indexed, and after deploying the app we end up tanking our database performance, right? That seems like a huge potential issue to me, but I might be misunderstanding how it works in practice.
  • jensneuse 6y ago
    This is not an issue from my point of view. If you do GraphQL the right way you'll always use persisted Queries. For each persisted Query you know exactly how it behaves and you can test it before you go to production. WunderGraph uses persisted queries by default. We don't allow arbitrary queries at runtime. Here's a post on the topic if you're interested to dive into this a bit more: https://wundergraph.com/docs/concepts/persisted_queries https://wundergraph.com/docs/concepts/persisted_queries
    • barumi 6y ago
      > This is not an issue from my point of view. If you do GraphQL the right way you'll always use persisted Queries. But that's not using GraphQL "the right way", is it? I mean, GraphQL's value proposition is quite literally letting front-end developers run all sorts of ad-hoc queries without having to bother about indexes, and only care about the data you wish to extract. If all you want is to run fixed queries then you're already better off putting up a REST API.
      • diveanon 6y ago
        Front end developers are api consumers in the same way that a third party client is. As others have stated persistent queries are the answer. You can disable them in local dev if you want to give your devs more flexibility, but I have found it usually isn't necessary.
      • 6y ago
• sfmth 6y ago
  hello how can i get karma
  • jensneuse 6y ago
    Sit down 5 hours and write good content on a topic that you understand and that matters to the community. Then try to post on the right time. I didn't expect anybody to read this to be honest. I just posted it and got back to coding. Then I had a look and was amazed by the reactions. I posted it a few days ago on reddit/r/graphql but didn't get much attention. Believe in yourself and try to write good content. Don't try to get karma. Content is valuable if it starts an engaging conversation.
• edem 6y ago
  I'd turn this question around. Why use it?
  • Mountain_Skies 6y ago
    One of the reasons why Facebook created GraphQL was to reduce the payload size of the results, which often include large amounts of data that the current task did not require. There are ways to address this with REST, mainly though creating additional endpoints, but that quickly grows out of control for complex applications and requires touching multiple application layers. With GraphQL, the consuming app specifies what it wants returned, and only that data is sent. For Facebook's mobile apps, this worked well because you might only want to retrieve a person's name and not care about the other 10,000 bits of personal data Facebook has accumulated about them.
    • folmar 6y ago
      I've seen it adressed with and additional parameter ?field=list,of,those,you,want in a few big commercial applications. It did not file REST-way to me, but it is easy and works both server- and client-side.
      • valenterry 6y ago
        Sure. And then you also want to query subfields, you can extend your query parameter list with some specific scheme for that (e.g. `subfields=fieldX.subfieldX,fieldY.subfieldY` - and then you can enhance it with filters, mutations, recursion, introspection, types, documentation, deprecation features... and then you have built your own version of graphQL. At some point, it is better to leave the custom solution field and go for graphQL before rebuilding it.
• ex3ndr 6y ago
  The main issue of GraphQL is awful tooling, especially outside of the js. For example, we have done small rewrite of Apollo Android library and achieved like 100x performance boost simply by writing as it should be written. Literally very minor changes and better DB. Typesafe codegeneration? Still feels very beta anything your could find. Compare it to something like grpc that have strict typed clients for almost anything.
  • rattray 6y ago
    This was a big reason we decided not to release a GraphQL version of our REST API at my previous employer. Most backend languages have poor gql clients, if any at all. Better to just provide a nice, typesafe client library generated from OAS.
  • hobby-coder-guy 6y ago
    > Still feels very beta anything your could find. ?
  • stephen82 6y ago
    When should we expect an article about this? I'm all eyes and ears!
  • georgyo 6y ago
    100% this! Outside of JS, the tooling seems non existent. What's so amazing to me is that it is really easy to spin up a server that talks graphql in any language. But there is no client support. And hand crafting queries is a million times worse than reading the rest documents Oh, you want to get a list of items by owner, you can do that but you'll also have to paginated the inside and outside list. And the client will have to follow these pages while also having a deep understanding of your model. Without good client tooling, graphql is a nightmare.
    • initplus 6y ago
      It's easy to spin up a server. Spinning up a server that can actually access your data in a way that has reasonable performance is another matter entirely.
• GiorgioG 6y ago
  Why not use gRPC?
  • PebblesHD 6y ago
    If you’re after raw speed I can see this but it’s near impossible for a human to parse and requires a spec to implement a client which means it picks up what I personally feel are the worst parts of the other available options with only one benefit. Some use cases make the speed alone worth it, but like graph I don’t think gRPC is as generally useful as the alternatives.
  • aloer 6y ago
    How is the grpc support in browser/web js? https://grpc.io/blog/state-of-grpc-web/ https://grpc.io/blog/state-of-grpc-web/ is from early 2019
  • diveanon 6y ago
    gRPC is coupled to individual services whereas graphql gives you an abstraction layer that allows you to expose your data in a controlled manner while allowing you the flexibility to refactor the underlying services whenever you want.
  • RedShift1 6y ago
    Different solution to a different problem
• dec0dedab0de 6y ago
  Because GraphQL is difficult to explore. I want to write code without knowing anything about your API before I start. That said, I absolutely understand the appeal if you're writing the client and the server, and don't care about your API users. Edit: Since I got a bunch of questions that seemed to be the same. The few times I've used a graphQL API i was expected to know which attributes I was requesting per object, instead of just getting them all and figuring it out later. That was my main concern. I want to find an endpoint, get a list of objects without knowing what will be in them and start throwing stuff at it. I usually do this in python using jupyter, so when I'm finished exploring I have working code that just needs to be refactored a bit to fit into wherever it's going to go. For me, this workflow is usually faster than even finding the documentation on most systems. But yeah i apologize for my early morning crankiness, I was really complaining about a few specific implementations of GraphQL that I found frustrating. And to be fair these specific companies I'm thinking about also had annoying REST/SOAP APIs in the past and are now touting GraphQL as a sort of silver bullet.
  • gedy 6y ago
    ? Implementations I've seen have the ability to show schema & documentation that you can explore via the client side. GraphQL Playground for running queries, etc.
  • dudul 6y ago
    I have no clue where you're coming from. Graphql is fully explorable by design, its in the actual spec. This actually solves a true problem with rest apis, half assed, outdated docs.
    • RedShift1 6y ago
      GraphiQL is so nice. Just tick the boxes of the data you want, boom, done. Don't even have to read any docs to get that done.
  • diveanon 6y ago
    I disagree 100% Graphql coupled with graphiql is extremely easy to explore. So easy in fact that we have replaced all of our api documentation with graphiql instances that we provide to our clients. I would encourage you to learn more about the tooling before posting FUD.
• PebblesHD 6y ago
  The difficulty caching responses between client and server can’t be helping its cause either, nor the relatively immature state of the tooling around graph. I do feel it has some interesting advantages with selective queries and such but at the moment I still don’t think it’s ready for prime time.
• netfl0 6y ago
  I think even the name overstates its capabilities. Compared to something like sparql it is a comically limited language only suited for front end syntax sugar, which is fine. But let’s not pretend that it’s going to change the world in a Michael Jackson sorta way.
  • diveanon 6y ago
    Graphql has already changed the world, it is used by several of the largest platforms on the planet.
• osxman 6y ago
  I like this genius title. You can read it both ways. To use or not to use.
• vmaurin 6y ago
  With GraphQL and single page apps, people tend to move their business logic to the frontend side. I am not sure it is a good idea seeing how moving are the frontend tech
  • andrewingram 6y ago
    Interesting observation, because my own experience has been the opposite. With GraphQL I've been able to more easily push business logic to the server.
  • dudul 6y ago
    Can you provide more details? I've seen the exact opposite.
  • meiraleal 6y ago
    My experience have also been the opposite. With GraphQL I can normalize queries and mutations the way it is more fit to the frontend and de-normalize/re-normalize it in the backend.
  • jensneuse 6y ago
    I'd say it's the opposite. GraphQL allows you to move data fetching and composition logic to the server (resolvers) instead of doing it in the client.
  • diveanon 6y ago
    I disagree, we are using Hasura heavily and most of our business logic is in stateless functions called via db triggers and hasura actions. It is very easy to provide additional graphql schemas that expose business logic as a remote schema.
• weego 6y ago
  For me GraphQL is the epitome (in the Web tier) of 'we need to solve the same problems as FAANG does'. You'll likely never be in a situation where over-querying via a non-granular REST call will ever be an issue worth optimising around. If you're shipping multi-megs of JS to a client don't then pretend that micro-optimisating the API call waterfall is your KPI, it's just disingenuous at best. At best it's a band-aid around dysfunctional inter-team working.
  • kochthesecond 6y ago
    I dont disagree with this, but I also see in our case that good tooling is immensely valuable in keeping things consistent and moving forward (in the same direction) without having to discuss every change.
  • jmnicolas 6y ago
    > You'll likely never be in a situation where over-querying via a non-granular REST call will ever be an issue worth optimising around. While I agree with your beginning sentence, the one I quoted doesn't sit well with me. It would be good to remember that not everybody has 100 Mbits fiber or 5G download speed. We all saw the data on how milliseconds affect user retention then proceed to completely forget about it once building our apps. I think we can do better.
    • HeyHoJoe 6y ago
      Even if users don’t have 5G, why is your rest api so slow that it’s an issue? Why is graphql the solution? The featured article points out that optimising rest can be a better solution, in terms of time and effort, than implementing graphql. The problem that graphql solves isn’t this one.
    • jamil7 6y ago
      Agreed but I think the point was over fetching is likely very far down the list of optimisations.
  • ryanar 6y ago
    GraphQL also allows the frontend team to iterate faster, because they don't need to ask the API team to change an endpoint, or add one. The API team also moves faster, they define the relationships and they are done, no going back and updating endpoints. GraphQL creates a data graph that powers the UI, REST creates a database that you can query on the UI and you have to compose it all together and manage.
• philplckthun 6y ago
  Core Contributor of urql here, another JS GraphQL client. I think this post is very good at stating why the particular post it’s referencing (“Why GraphQL” in the Apollo docs) isn’t a full picture overview, and it succeeds at that very well, but I think it doesn’t go on to expand on these views just as much as I’d like to. If we look at popular comments by the GraphQL community on this it isn’t hard to find that “the quickest & easiest client is to just fetch a GraphQL API” (similarly said quite frequently) and that’s an excellent point. But going on to say: > However, you should always consider the cost of adding a GraphQL client to your frontend. This is definitely true, but as a creator of another GraphQL client I’d say that there are major benefits as well, the main selling point of Apollo, Relay and urql (for the latter this is optional) being that you can utilise a normalized cache. But these tools often provide great frameworks to solve some of the problems that are stated to be woes with GraphQL, like persisted queries, subscriptions, file uploads, etc. So they’re a great starting point to dip into multiple parts of the community and get out-of-the-box solutions for your problems. And generally I’d say that sums up GraphQL: it’s not novel or anything new. Instead it combines a lot of ideas into a solid community and ecosystem. With tools like Swagger or gRPC it’s easy to see how any part we look at for GraphQL isn’t novel. What is great is that the exact set of problems it solves it does so with a larger (and growing) community and a standard that encompasses multiple of these solutions. Finally, I’d say again, GraphQL clients and servers aren’t “all of GraphQL,” Apollo isn’t GraphQL (although they’ve made themselves synonymous with it) and hence there are different tools, clients, and libraries to create GraphQL servers, clients, and interact with GraphQL APIs. As a user you’ll still have to choose, but a lot of the good parts come from agreeing on one language and standard that allows for introspection and the ease using which we interact with these APIs on the client-side, from simple HTTP calls to more complex caching clients.
  • jensneuse 6y ago
    Hey, thanks for your reply. I think you guys have done an amazing job creating a very powerful GraphQL client. However, to me "smart" GraphQL clients don't make much sense. My approach with WunderGraph is the following: You write down all your Operations using GraphiQL. We automatically persist them on the server (WunderNode) and generate a "dumb" typesafe client. This client feels like GraphQL and behaves like GraphQL but is not using GraphQL at all. It's just RPC. This makes using GraphQL more performant and secure at the same time. Additionally it's a lot less code and a smaller client because those RPC's are a lot simpler.
• knlam 6y ago
  Compare to REST, GraphQL have many advantages. However, IMO the tooling is still not there yet (Especially the caching, batching/data loaders are PITA). One of the biggest selling point rarely come up is that you get the API docs for free through the playground. No more Swagger bad API
  • capableweb 6y ago
    You might get reference documentation for free but you don't get real, proper documentation that actually teaches the user anything. So basically the biggest selling point (for you) for GraphQL is the same as biggest selling point for Swagger? The quality of those reference docs is more based on the developer writing them, rather than the technology who allows it.
    • diveanon 6y ago
      Can you define "real proper documentation"?
      • capableweb 6y ago
        I'm only contrasting it to reference documentation. So in the case of GraphQL, you get reference documentation that shows you exactly how it can be used. But it won't show you _why_ you'll use it, or _what_ it can be used for. It also doesn't show what invariants you're working with, or in what way the endpoints are otherwise restricted with. Real proper documentation is not just a list of endpoints and their attributes but explanations of those as well as other things.
        • diveanon 6y ago
          I don't see how that is in any way specific to REST or GQL.
          • capableweb 6y ago
            The original comment said "One of the biggest selling point rarely come up is that you get the API docs for free" while comparing it to Swagger. Both GraphQL and Swagger gives the same ability to generate API reference documentation. So how is that the "biggest selling point" of GraphQL when it's not even new in the ecosystem?
• calrain 6y ago
  It's incredibly difficult to optimize performance around. With REST, I know how the data is being presented, and can craft DB queries with focused indexes to ensure it's as fast as possible.
  • dudul 6y ago
    What prevents you from doing that with graphql? You're still getting parameters to use in your DB queries.
    • calrain 6y ago
      Being able to predict how your customers use your API has a strong impact on how you deliver the data behind the API. If we're talking about highly interconnected objects in an API, it would be expensive (from a DB point of view) to arbitrarily add indexes in the long shot case that someone may use a selector on that property. Equally, when data is highly interconnected, by designing an API that focuses on particular consumption patterns, I'm able to add custom functionality, pre-processing, or highly customised queries/indexes to ensure the data is read as fast as possible. Poor performing API's are bad for the consumer, bad for the database, and bad for the art of data. There's a balance between centralization and independence in software models that is so hard to balance right. MicroServices, GraphQL, and Docker Swarms are examples of technologies that, if done right, can be enabling, and if done wrong, will pull the ship to the bottom of the ocean.
  • andrewingram 6y ago
    It's not that hard. For sure it's not trivial, but the thing you just said about REST is equally true for GraphQL -- you can literally solve performance in the same way. Ultimately fulfilling the data requirements for a use case boils down to composing the results of a bunch of I/O calls, the only real difference between REST and GraphQL is how these calls are triggered and their results composed.
    • initplus 6y ago
      Sure, but the design of GraphQL, and the majority of the GraphQL backend tooling, lends itself to performance issues much more strongly than a boring REST API. I don't know if there are alternative backend tools, but my experience has been quite painful. The "graph" part - GraphQL seems to want you to build these big interconnected webs of types. But there isn't good tooling on the backend to deal with resolving relationships between types efficiently. Someone decides they need user.friends.pets.names, and now my backend code is doing 3 DB round trips because my GraphQL server lib doesn't understand it can turn the relationship between the types into a JOIN. I decide that's no good and the query needs to be faster, the alternative is I have to do the JOIN every time even if the client didn't actually request friends. And if I'm going to overfetch from the DB, might as well send that data to the client anyway? My experience was that because of how backend GraphQL servers are written, it becomes very challenging to reason about performance. It's hard to think about how your nice type resolvers are going to interact, and fan out into some nightmare n+1 query problem performance pit. I know there are some better tools than this, which I sadly haven't tried...
• codegladiator 6y ago
  GraphQL is not like REST at all because if something is not defined in GraphQL, it cannot be done. For instance Graphql servers cannot have dynamic fields in models (example aggregate queries) https://stackoverflow.com/questions/45842544/graphql-objecttype-with-dynamic-fields-based-on-arguments https://stackoverflow.com/questions/45842544/graphql-objectt... In REST, I can send the columns and know what I am going to get back. All the queries need not be defined to start with.
  • philplckthun 6y ago
    That’s a pretty misleading statement, since what you’re linking to does describe how using scalars can help. Especially if the scalar never includes other data from the graph (other objects) describing the custom format with scalars is just fine.
  • odshoifsdhfs 6y ago
    I created a no-code tool that could do joins, filters, and more with GraphQL, so I really don't see your point. You just need to do it a bit differently (same as REST, and if you follow REST 100%, good luck with n*m calls when you want to join two resources that you don't know from the start): GET clients [client 1, client 2] for each client GET business (id = client.id) Now think you can join with business, jobs, invoices, employees, etc etc, and tell me how to do this in rest without basically recreating a query language?
    • codegladiator 6y ago
      Try to build an aggregate API over graphql. Where all sql functions are allowed on appropriate columns.
      • odshoifsdhfs 6y ago
        I did, the same way you would do with a REST API. you specify a format for a field (in my case, the 'where' and 'join' where JSON structures that you passed as parameters) Then you write the resolvers that parse that. Pretty much as I would expect you to do it in REST. (mentioned it in another post, I created a no-code tool that did this, for random data and entities created by the user per tenant/app, so I know the issues with GQL, but I can assure you, doing the same with REST was 10 times harder (api started as REST and moved to GQL after 6 months)
• jefflombardjr 6y ago
  > My personal pet peeve is when the community keeps advertising benefits of GraphQL that are very generic and really have nothing to do with GraphQL. Douglas Crockford taught me a really valuable lesson here... in Javascript: The Good Parts he had something directed at the haters of Javascript, that stuck with me. But I think it applies here too. GraphQL and REST are tools/patterns that have pros and cons. All tools have pros and cons. Why would you get mad at a hammer for not being good drill? Because that is what people do in our industry and it's silly. I tried two years ago to write an article with this in mind, and the conclusion I came to in How and When to use GraphQL [0] is that it is an abstraction. Nothing more, nothing less. It's up to the individual to determine whether that abstraction makes sense to them. Haters are always gonna hate, and I do appreciate your taking the time comparing and contrasting the two. Too often articles that say "Hey wait a minute here, we might be drinking the koolaid for x" come across as contrarian and spiteful. I think you managed to keep a respectful tone while asking important questions. Thank you :) 0: https://medium.com/@JeffLombardJr/when-and-why-to-use-graphql-24f6bce4839d https://medium.com/@JeffLombardJr/when-and-why-to-use-graphq...
  • jensneuse 6y ago
    Thank you! When I was less experienced I introduced a lot of technologies to the companies I was working for. I thought I'm doing the right thing. If I were fully honest I just thought these tools are amazing and I wanted to have a play with them. Over the years I learned that I was wrong a lot of the time. I introduced kubernetes to a company that never really had the need for it. It wasn't the right move for them. I didn't fully understand the business. I think, as developers, it's important to develop balanced views and get better at decision making. It's important to not focus on tech too much but understand the business implications and derive the strategy from that.
    • k__ 6y ago
      This is a huge problem for devs. Junior devs neither understand the business nor the technology, but they get promoted to senior dev anyway after 6 months of bootcamp and 2 years on the job.
    • 6y ago
• ritchiea 6y ago
  This is a refreshing read, every time I ask someone what they like about GraphQL or read an article about the benefits of GraphQL I get the same boilerplate, non-answers that made me avoid GraphQL on my latest app after working with it on 2 freelance projects over the last couple years. The tooling around Apollo is pretty good, and that’s great but so many of the “why GraphQL” arguments are either short sided, assume you are doing REST badly, or imply you are an organization that is much bigger and has scaling problems most of the projects I’ve worked on do not have. So far I am very happy I went back to a REST API. Oh and here’s another REST benefit: when working on my REST API I spend most of my time thinking about good API design and testing practices. When working with GraphQL I spent most of my time figuring out how GraphQL ecosystem libraries worked. I would much rather spend my time thinking about how to do the job well than how to glue together an ecosystem of tools that someone else designed. Admittedly this is a very subjective line to draw, for instance I loved Rails and some people make the same criticism of Rails that I make here for the GraphQL ecosystem.
  • golergka 6y ago
    GraphQL is great when your entities are complicated and interconnected with each other. If you just need to get one user object, it's not different from rest. If you need to get user, then 5 of his posts, then 50 of comments for each post and then 100 reactions for each post, all connected by IDs in your DB, GraphQL allows you to do all of this in a single HTTP request, single SQL query and with 0 lines written by backend developer. (This example is pretty silly, but I have very similar and not silly examples that I just can't share because of respect for my employer's NDA).
    • vidarh 6y ago
      My experience is that giving front-end developers who does not understand databases the ability to do this is a great way of killing performance across the board. I don't particularly want that to be easy, because I've too many times had to clean up the consequences. If you have a team where everyone understands the database implications, then awesome. In that case this consideration may not apply.
• dave_sid 6y ago
  I’m not an expert but it feels like GraphQL is a solution looking for a problem.
  • jensneuse 6y ago
    If you look at the history you'd see that the people who invented GraphQL at Facebook were looking for a solution to a problem, not the other way around.
    • dave_sid 6y ago
      I knew my comment would get voted down. Never criticise React of GraphQL.
  • diveanon 6y ago
    Then why post this comment?
    • dave_sid 6y ago
      Why post your comment?
      • diveanon 6y ago
        Because I'm not making an assertion from a self acknowledged position of ignorance.
        • dave_sid 6y ago
          But why post this comment?
• realce 6y ago
  GraphQL support in Django is a dark beast. Graphene doesn't even support subscriptions out of the box, finding tutorials is difficult! For the DB we use it for the querying syntax is way better, but anything other than a basic query is black magic and crossed fingers.
  • d_rc 6y ago
    Totally! We're trying to build a GraphQL API generator on top of Graphene and it's just ... well sad.
    • realce 6y ago
      I can see the promise of it, but getting there is so cumbersome. In our implementation it's supposed to provide a level playing field between devs working on a react app and devs working on internal sites that are django template powered. In a strict query sense, if you roll it with DRF auth and use an auth token in every query, it's very flexible for us. But even things like partial mutations are fuzzy. The auth packages for it are immature, the integrations with channels is immature.
• diveanon 6y ago
  Graphql is a huge improvement over REST, and I don't see myself or any team I manage going back. We provide legacy REST api's for some of our clients, but we are using Graphql internally. Coupled with Hasura (https://hasura.io/ https://hasura.io/) you have an extremely flexible, safe, and automated api that can consume multiple data sources and integrates very cleanly with serverless architectures. A lot of the comments in this thread read like pure FUD, and I would encourage those of you on the fence to do your own research and evaluation before listening to the crotchety old devs (disclaimer: I am a crotchety old dev) here who are afraid their REST chops are obsolete.
  • jensneuse 6y ago
    I don't see how you back your statement with any real arguments. Why do you think it's an improvement? A lot of the time people argue GraphQL is better than REST, what they actually mean is that they didn't want a set of conventions but rather an opinionated framework that made the decisions for them. REST gives you a lot of freedom to do it wrong. GraphQL on the other hand makes some assumptions and decides a few things for you. This makes it easier to use if you don't want to dive into the complexity of designing and building proper REST APIs. The outcome will be more or less identical.
    • diveanon 6y ago
      Because those conventions are rarely ever followed. That freedom to do wrong is not a perk for most organizations, and having an opinionated and consistent data layer provides a lot of value to large teams. That coupled with GQL automation and type generation has literally taken months off of the development cycle for the last two products I've built. That has a real $ value that has led to actual success for those products. Not to mention that these API's are extremely flexible for the end user in a way that comparable REST api's could only dream.
      • jensneuse 6y ago
        I really like your answer. I think that's a very good argument if you want to convince someone to start adopting GraphQL. Do you have anything beyond that?
• booleandilemma 6y ago
  Because REST exists and it’s well understood and easier to use?
  • jensneuse 6y ago
    I don't think REST is well understood. Who does really understand the richardson maturity model? Who understands HATEOS? REST is a set of constraints. The implementation is up to the user. There's no requirement to document, it's optional. You can have an Open Api Specification, you're not forced to do so. GraphQL on the other hand is a lot more specific. It makes a lot of decisions for you. It's less flexible in that way but this also makes it easier to use.
• golergka 6y ago
  Searched the article for the word "join", no hits. Strange: this is my personal top counter-argument to use GraphQL. On my current project, we're using Graphana with Postgresql on the server and Apollo on the client. You create a new table in database, click a couple of buttons in Graphana admin panel, and the client now can query those tables, without a single line of code on the server! This part is awesome. What is much less awesome though, is when you have a normalized database, and entities with many layers of links, and your client can generate GraphQL queries with so many crazy joins that will take your production database 30 seconds to complete — all while accessing public data, with no authentication required. So far, I haven't seen anybody figuring it out to DDoS our server, and every time this happens with real production queries, I get a fun index writing task. However, just being able to run into database perfomance limitations by writing code on the client seems wrong. There's always going to be weird joins that we won't optimise for, and sooner or later there will be determined DDoSers who will figure it out and will be able to spam our server much more effectively with each query. I'm not yet sure what's the right way to alleviate this problem is, it's just strange that no one is talking about it. Edit: I think I have been proved wrong by lukeramsden's comment below; or at least I should research this more before having an opinion on this matter.
  • lukeramsden 6y ago
    A good page for this is Postgraphile's "Production Considerations" page [0]. Under "Denial of Service Considerations" it talks about a few solutions, such as statement timeouts, persisted queries, or query analysis. Choosing what to use may be quite project specific but there are available solutions. [0] https://www.graphile.org/postgraphile/production/#denial-of-service-considerations https://www.graphile.org/postgraphile/production/#denial-of-...
    • golergka 6y ago
      Thanks for this! Immediately forwarded it to my team chat, this is incredibly useful. Turns out that they already researched these options and just haven't invested any time in them because it hasn't been a real production issue, so I probably should take my criticism back.
• laststand 6y ago
  I see GraphQL and other tools created by FAANG companies being used all the time by 1-3 person teams. Their applications are often slow and poorly made. I say that because initially I felt like maybe I wasn't being "professional" if I didn't use these tools, but actually using their applications reassured me that I was going in the right direction. I see people use GraphQL as the new ORM. I see it used by people who don't have that much experience with databases. I see it used by people who have nothing much to do. It is sometimes about cost requirements. You can just spin up one of those automatic graphql servers that creates the entire backend for you. Sure it doesn't have any logic or security or performance, but it was quick to get up and going and the client is not experienced enough to notice in the beginning. It is often used with Apollo client, so these inexperienced developers then have all kinds of caching issues due to the automatic caching the client does that they don't really understand. I see it having an application at FAANG scale, where there are teams of front end and back end people, and front-end people can just create the UI without talking to the back-end people. I see it being used at places with enough scale to have multiple graph databases, not SQL databases, or multiple types of databases that need to be unified. That isn't where it is used in most cases though. It ends up being a very limited version of SQL that is slow. I think it would be good for maybe a public API.
  • jensneuse 6y ago
    While you're right I see another trend as well. Multi national Fortune 500 companies with many many sub organizations and hundreds or thousands of engineers who try to find a way to scale APIs for them. Not saying REST is no solution to them but GraphQL, especially with schema stitching and/or federation can definitely help in this case to organize the API landscape.
  • RedShift1 6y ago
    I use GraphQL all the time in conjunction with PostGraphile https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ and let me tell you, it's definitely not slow. If anything it is very fast. But just like REST or anything else, if you do a poor implementation you will get a poor result: garbage in, garbage out.
  • ritchiea 6y ago
• LibertyBeta 6y ago
  I don't get the love/want for GraphQL clients. Sure they are nice to get started but like ORMs they are needed until you hit a certain level of Team/Project scale. That said it's good to see a counterpoint to the GraphQL push. With gql, gRPC, etc, it's a great time to be working with APIs.
  • jensneuse 6y ago
    Have you ever hit a point where you scaled beyond a point where GraphQL clients were usable? Apollo, urql etc. look quite flexible to me, I've never had such issues.
  • GordonS 6y ago
    IME few people hate GraphQL, they just hate being told to use it instead of REST because of a cargo-culting architect. GraphQL absolutely has it's place, as others have eloquently described here, but it shouldn't be the default choice for small teams "just because".
• cwhiz 6y ago
  I can’t ever go back to REST from something like Hasura. It’s just too easy, too fast, and too flexible. Some of the comments about performance and security are obviously from people who haven’t taken the time to do a proper deep dive. I’m sure there were similar arguments against REST from the SOAP crowd.
  • lukeramsden 6y ago
    Same but Postgraphile, the whole ecosystem of migrate and worker too. Allowed me to iterate so damn quick.
    • k__ 6y ago
      Won't such an approach lead to tight coupling between database and API?
      • jensneuse 6y ago
        You're right if you're directly exposing your Databse-driven-GraphQL API to the client. If you use GraphQL to power your REST APIs this is less of an issue. On the other hand, tightly coupling your database to a client doesn't always have to be a bad thing. If you outscale a single Postgres Database with Hasura you can add read replicas. If that still doesn't work you can add Yugabyte to the mix to scale further.
      • lukeramsden 6y ago
        It can do, however you can also use views, custom query functions for whole queries or for specific columns, custom mutation functions, or simply extend the schema at the Node application level to do a lot more than just the structure of the DB tables. For me it just means I don't have to write any code other than the schema to simply expose CRUD actions with filter and sort and such things - the escape hatches have been perfectly adequate for more complex behaviour.
  • ingas 6y ago
    I like hasura too. But honestly absolutely the same result could be achieved with REST too. GraphQL is not that different from REST.
• rattray 6y ago
  This is a bit of a sidenote, but I hadn't personally been aware of Next.JS's BFF (backend for frontend) approach before, and it looks pretty magical (I mean that in both good and bad ways): function Page({ data }) { // Render data... } // This gets called on every request export async function getServerSideProps() { // Fetch data from external API const res = await fetch(`https://.../data`) const data = await res.json() // Pass data to the page via props return { props: { data } } } export default Page Docs: https://nextjs.org/docs/basic-features/data-fetching#getserversideprops-server-side-rendering https://nextjs.org/docs/basic-features/data-fetching#getserv... I have a hard time imagining this kind of architecture scaling well to Real Production Applications, but for whipping something together it does seem incredibly easy.
  • jacobr 6y ago
    API routes is what they refer to with the Next.js BFF approach: https://nextjs.org/docs/api-routes/introduction https://nextjs.org/docs/api-routes/introduction It’s useful if you need to call an API from the client in a Next.js application but modify the data first, or call multiple endpoints without introducing a waterfall to the client. What you described can be used in a similar way for filtering and processing etc, but only for the initial page load.
  • jensneuse 6y ago
    I think this can work very good at scale. Create a well designed REST or GraphQL API, depending on use case. Then use this API inside the Next.JS API routes. Obviously, if you stick your business logic into the API routes this will become a mess if you plan to add other API consumers. On the other hand, if you never want to add other clients to an API, this could be less of an issue.
• spockz 6y ago
  One of the issues we are facing is that changes in type definitions take a lot of time propagating from the SoR layer to the front end. Imagine the addition of a currency attribute to the list of accounts. In Theory only the client and the SoR should be impacted but in practice all services in the middle are as well because they serialise/deserialise and operate their business logic on this. Most often this business logic is just permission checking, routing, and aggregating. Is there anything already which lets you deserialise in your view but allows the original body to be forwarded or aggregated. Of course we could pass around all original strings/payloads but that would be complex and error prone.
• BLanen 6y ago
  > I think GraphQL will change the world. There will be a future where you can query any system in the world using GraphQL. I'm building this future. This is just extremely embarrassing to say. 1990s John Perry Barlow esque fantasy. It will do no such thing and nothing ever will. GraphQL completely unfit for purpose for any purpose. It's not even a Query Language. It's as much a query language as JSON. You have to build almost everything yourself. At least REST uses the standard HTTP status codes for stuff, in GraphQL you have to roll your own for EVERYTHING. And thus EVERY COMPANY WILL DO IT DIFFERENTLY even more than REST Apis are different because there is no expectation to conform to anything. Most resolver libraries are also completely naive. It's like facebook was just intentionally trolling.
  • barumi 6y ago
    > GraphQL completely unfit for purpose for any purpose. It's not even a Query Language. It's as much a query language as JSON. You have to build almost everything yourself. Here's an idea for pet project: an interface for NoSQL databases where the input is a jq filter command and the output is JSON. jqml? GraphJQ? It's up to you.
  • mrmonkeyman 6y ago
    The future is REST APIs wrapping custom JSON APIs, exposed with GraphQL on serverless k8s all wrapped in a VM on a Raspberry12 in some kid's locker, which itself is simulated on a large instance on AWS.
  • corytheboyd 6y ago
    Yeah I immediately stopped reading there too. GraphQL does nothing new. I think it’s useful, and would rather see it used that some in-house alternative, but it’s not revolutionary lol
• unityByFreedom 6y ago
  I tried Hasura's GraphQL implementation. I liked the ease with which you can set row/column-level permissions. However, REST is so much easier to build and query. Normal APIs use GET requests which are easy to cache in a cdn. GraphQL uses POST by default and to cache that you need to convert the request somewhere, either in the cdn or your web server. At the end I realized I was just messing with it for a small project to learn it. It really isn't worth it IMO. The problems it claims to solve can be solved with REST provided you understand the issues.
  • bpicolo 6y ago
    > uses POST by default I've found that this leads to a huge miss on the observability side. The ecosystem of tools doesn't solve for this well today, especially when it comes to the various vendor integrations.
    • unityByFreedom 6y ago
      Yeah. I can see why they do it because you need to list every darned field in the query and that can get pretty long. It'd be manageable with GET query parameters if there were simply a way to specify "include only these fields" or "exclude these fields"
• austinhutch 6y ago
  I very much appreciate the author's approach, and giving a sober perspective on GraphQL. Working within the Shopify ecosystem, they have invested heavily in GraphQL and I don't like the UX, nor do I find the reasoning to promote it over REST particularly convincing. It has been much more difficult to grok GraphQL over REST and I don't think I'm alone. There are likely specific use cases where GraphQL > REST but the barrier to entry is so much higher that I think you'll continue to see the interest wane[1] unless something dramatic changes [1](https://trends.google.com/trends/explore?date=today%205-y&geo=US&q=graphql https://trends.google.com/trends/explore?date=today%205-y&ge...)
  • jensneuse 6y ago
    Do you have ideas on how the situation could be improved at Shopify? What makes it hard to understand? What's missing?
    • brod 6y ago
      I think there is some difficulty specific to Shopify here, as REST APIs go their original one was fairly sane and provided powerful features. When their GraphQL API was released its data structures were similar but not identical to the REST API and some very important fields and features were missing which translated to a "90%" adoption by developers who needed those missing pieces. Additionally (and somewhat in keeping with points in the article,) they also introduced API versioning at this time which added a good amount of friction within the community. More generally the issue with Shopify's GraphQL APIs is its lacking features (eg, list totals, offset pagination, object fields) which are (or had been) particularly important to the ecommerce domain and they've struggled to provide any meaningful alternatives. As an example, developers working with ecommerce applications often have to process data en masse (fulfillments, inventory, etc..) and with the Shopify REST API and it's offset pagination these tasks were trivial to parallelise by simply chunking the workload based on the pagination method. In the GraphQL API offset pagination was removed in favour of cursor pagination which has no reasonable alternative to parallelise tasks in the same way, this requires developers to rewrite core logic and services for what may have previously been a very acceptable, efficient and most importantly working application. The issue with Shopify's GraphQL API is not GraphQL itself, but rather the implementation of the API not meeting the requirements of the consumer - and the fact that those consumers were forced to switch to a different API without feature or even conceptual parity didn't promote feelings of joy or glee about the situation. Personally I think their push for GraphQL was due to internal operational issues and their need for a more efficient system. This has been seen in their reasoning for reducing the timeout of an API used to fetch shipping options (from 10 seconds to 5 seconds) in preparation for Black Friday / Cyber Monday sales events, their announcement provided some developers less than a single business day to respond to the changes[1] which were dropped after community backlash and then changed to address the feedback. [1] https://community.shopify.com/c/Shopify-APIs-SDKs/Changes-to-CarrierService-API-rate-request-timeouts-10s-gt-5s/td-p/893703 https://community.shopify.com/c/Shopify-APIs-SDKs/Changes-to...
• nsenifty 6y ago
  GraphQL is great when you have multiple apps (e.g. web/android/ios) querying the same set of backend services. It is quite hard to define REST interfaces in a way that is optimal for all clients, unless you want the client to do a bunch of extra work (n+1 queries or other type of aggregation). The author mentions the BFF pattern which could work quite well along with REST, but has not worked out for us in large teams. We ended up with BFFs specific to each client type which all do the same things in slightly different ways and it was hard to share code and do things consistently. With GraphQL, all the previous BFF logic was centralized in one place but each client could still fetch data in different shapes.
• Udik 6y ago
  I'm not particularly familiar with GraphQL, but this article highlights a common problem in the promotion of new libraries, patterns or methods. These are usually advertised as having a number of independent benefits or solving a series of unrelated issues, but when you look into each of them, it usually turns out that the same advantage can be easily obtained by adopting much smaller changes on top of the current tools. In the end, the question that proponents of a new technology in a team usually avoid addressing is: "what specific problem we have here and now that this new method solves, and why can't this specific problem can't be solved by the simple addition of X to our current solution, without the need to change absolutely everything?" Because even if a new library solves a laundry list of issues, usually the ones that need to be solved in a specific context- the bottlenecks- are just one or two. And those usually can be solved by small incremental changes.
• platz 6y ago
  Any post that claims to have engineering value that doesn't include the cons with the pros is in fact a marketing piece.
• platz 6y ago
  When GraphQL comes up there is always a lot of talk about the frontend (justifiably), but I never hear anything about what the story for the backend will be. Are there any unique challenges, assumptions, tradeoffs? The backend seems like a black hole of information in the GraphQL content that gets pushed to news aggregators.
  • filleokus 6y ago
    I agree! One thing to consider is that it depends a lot on the way you decide to use it. On one "extreme", you only have predefined queries, meaning it could almost be implemented the same way you implement REST API (however you decide to that). On the other extreme of the spectrum, you allow the client to query the data with much freedom. This means that you have more of a generic resolver which maps GraphQL queries into an ORM or something else that generates your DB queries. In this mode, you have challenges regarding speed and optimisations. At a previous assignment we for example hand crafted the resolution of some especially nasty queries to increase performance, and left most for some ORM to figure out. We kept the database index structure up to date to match queries we saw from the frontend using metrics tools. Another thing is security. If you use this model, you are basically allowing the client to query around your graph of data in whatever way they want. This means you need to have some way to answer the question "Should User 37 be able to read field X on Object Y with ID 42", and implement that in your resolver. This is quite tricky, compared to REST or static graph QL queries where you just decide which objects / fields should be returned. (There is also some interesting DoS attack scenarios when going this route, where a malicious query can just explode in complexity, so you'll have to make sure to solve that some way as well...)
  • zomglings 6y ago
    This is an astute question. I have only ever built a non-toy GraphQL server in 2016, for evaluation purposes. Never used in production. Tooling back then was probably much more primitive than it is today, so apply that discount to the subsequent statements. Writing GraphQL resolvers for the API that we were building was painful and required a solid understanding of our data model and what the database was capable of (we were using MongoDB). We were much happier at the time to stick to tried and true REST API tools and frameworks than to jump on the GraphQL bandwagon. All the complexity of managing REST calls was simply pushed from the client side to the GraphQL resolution server. This complexity seems irreducible to me, and I am highly skeptical of anyone claiming that they can make this complexity vanish. Have never so much as been tempted to use GraphQL since then. Unfortunately, this probably also marks my entry into dinosaur-hood.
• dnautics 6y ago
  Has anyone created a database where graphql replaces SQL? I can imagine many advantages.
• davidkell 6y ago
  We’ve trialled combinations of REST, GraphQL and gRPC-web across a bunch of different products. GraphQL has reliably won for us in trading off DX, UX and feature speed. Reasons - - Auto-generated, type safe entities from source to client, including relationships = fewer bugs - Ability to unify different backends (eg a database, warehouse, external APIs, cloud storage) - The “application data graph” concept always brings huge clarity to the architecture design - you get to build your mental model in code - GraphiQL is excellent Having said this, most of the benefits come from the incredible tooling, eg for our stack Graphene, Graphene-X bridges, Typescript, Apollo. I would never consider writing a GraphQL server from scratch, and we’ve had bad experiences with instant database -> GraphQL solutions (not really keen on writing my application logic in SQL). It’s also not an either or - our current app uses REST for file uploads and stream large datasets to the client. And ofc, you can achieve many of these benefits with other solutions. Wundergraph looks like a great addition to the ecosystem, it would already remove boilerplate from our app.
  • jensneuse 6y ago
    Would love to get in touch and discuss this further!
    • deleted 6y ago
      [deleted]
  • folmar 6y ago
    Did you trial the ususal suspects for getting those features you list, eg. REST+WADL, SOAP+WSDL?
    • foota 6y ago
      I don't think either of these are a usual suspect anymore. I hadn't even heard of these. Maybe these are more common in some parts of the industry.
      • tpxl 6y ago
• luord 6y ago
  Something I like about RESTful APIs over GraphQL[1] is the predictability. With GraphQL each request can depend on how the client constructed the query; with REST, every time you hit an endpoint, and assuming good practices such as idempotency are followed, you know exactly what data is being returned. Sure, these same restrictions are what can lead to the necessity of versioned APIs, but on their own, they make the API in general a little easier to reason about, and test, at least in some ways. [1]: Which is not to say that I prefer them nor I think them better overall. Much like TFA says, I think both approaches, and others, have their uses.
• pier25 6y ago
  Or, if you can, avoid having an API altogether with SSR.
• cbzehner 6y ago
  200 OK { errors: “This way lies madness” }
• Existenceblinks 6y ago
  Every time someone I know pride a technology tools, I often ask: engineering is cheap, show me the product you use this thing to solve. And most of the time I can see "no you don't need this".
• 02020202 6y ago
  why dont you just put your database on public port and be done with these charades?
• 3np 6y ago
  Everything around GraphQL seems to be assuming the client is user-operated such as a web or smartphone app, with the rare scenario of a node.js service being such a rarity that it takes some research to figure out if there's even a solution for it. Try to do anything beyond the basics with, for example, golang. This is completely fine and understandable given the use-cases that motivated it, and the community that's been driving it. But it's not a hammer for all nails. Reading the OP post, it's obvious they have a very narrow perspective when the one thing they compare it to is "REST". The nice thing with HTTP/JSON, and IMO a major factor in it's ubiquity, is that it's an OK (while not always ideal) solution to implement towards for pretty much any use-case. Performant and stable HTTP clients and JSON parsers/formatters are even part of a lot of standard libraries, and straight-forward to implement should you need to. The benefits of GraphQL compromise this. protobufs in general and grpc specifically are a much better solution for many scenarios, due to some trade-offs being different. A lot of the issues and concerns brought up by other commenters here is "leaky abstractions are gonna leak". I'm sorry, but there's no free lunch. IMO it's a bit delusional to claim with certainty that "There will be a future where you can query any system in the world using GraphQL". I'm not even sure I want o live in that future if it means 1) I have to support it and 2) it comes at cost of other protocols.
• 0df8dkdf 6y ago
  beacuse deep structure query sucks! And next thing you know you are installing abunch of npm package to prevent that. And I don't trust anything from FB including React!!
• k0t0n0 6y ago
  Am the only one who don't like working in graphql?
  • Eric_WVGG 6y ago
    It drives me bonkers. I absolutely hate the syntax… we already had an awesome powerful querying language in SQL. Not modern enough? Fine, give us something at least familiar with some structure like JSON or even YAML for crying out loud. I feel like whomever wrote the syntax of GraphQL was just concerned with getting it working with the least effort possible. (non-zero that person(s) is right here and reading this. I'm sure you're smarter than I am and I just haven't fully immersed myself into this world yet. It's happened before.)
    • Lx1oG-AWb6h_ZG0 6y ago
      I’d like to echo this sentiment - GraphQL’s syntax is very inconsistent, incomplete, and requires annoying gymnastics in application code for no good reason. For example, there is no way to represent a Record/Map type, so you have to transform it to an array of key-value pairs on the way down to the browser (and untransform it the way up). There’s an Int type, but no Long/uint etc. For any CRUD application, you have to define your types twice because Mutations can only contain Inputs, not Types. There is no union type for Inputs. You can’t express recursive types... I could go on and on. SQL would have been such a better choice. It’s been battle tested for decades and is so much more expressive.
• unodgs 6y ago
  In my last commercial project I used raw sql in the javascript code in a safe controlled way. I described it here: https://medium.com/@unodgs/sql-on-the-frontend-react-postgres-and-rls-part-1-76bbe4f97353 https://medium.com/@unodgs/sql-on-the-frontend-react-postgre... Very refreshing experience. I'll add summary post when my project is done.
• RabbitmqGuy 6y ago
  Github on moving to graphQL and then moving out of it again; https://lobste.rs/s/me5emr/how_why_graphql_will_influence_sourcehut#c_dl9vt8 https://lobste.rs/s/me5emr/how_why_graphql_will_influence_so... NB: I can't authenticate the veracity of the comments
• ndrestone 6y ago
  According to the post, the answer is: you should prefer to painfully rebuild everything the GraphQL specification simplifies using another standard. If this is not the answer, maybe the title should be "Why not use Apollo". Also, now that the specification is widely used and the problems it solves have obvious solutions, it's easy to tell how to reimplement those practices using another standard. The ecosystem only exists because the specification and the great thing is the many things you can achieve with it, not the tools that are already available.
• jbverschoor 6y ago
  GraphQL to me seems the exact same as opening an SQL interface to a db, and properly manage permissions :-) How would you handle schema changes in GraphQL? How to you administer who queries what?
• deleted 6y ago
  [deleted]
• koffiezet 6y ago
  From an operations POV, GraphQL is far from ideal. Every "GET" operation is a POST, there is no introspection and debugging requests is horrible. There are caching issues, and you need decent metrics and tracing across your entire platform to have any idea what's going on.
• wayneftw 6y ago
  > The console is a configuration only tool. It does all the things required to configure your projects, apply datasource transformations, propagate configurations, etc. It's a rather complex stack to operate and also our secret sauce so we don't want you to operate it. I don't need any specialized tools or secret sauces to build a REST server. I already know SQL and when my frontend needs something from the database, I simply write a query with that or do a fetch with my ORM, crafted specifically for that endpoint. Couldn't be simpler. GraphQL is a solution for building APIs when you aren't involved with the frontend at all. Even then the time invested learning, the extra layers of complexity, "magic" and tooling hardly make it worth the effort. I don't build APIs that way though. All of my APIs are purpose-built specifically for a given frontend and if I'm not creating both the frontend and the backend, then I'm closely collaborating with someone who is. Keep it stupid simple. This is the way.
• warent 6y ago
  Two of my favorite things about GraphQL are: - It has a well-defined pattern/structure so you don't have to waste a bunch of time thinking/arguing about what your REST endpoints look like. - It lends itself very nicely to automatic code generation for both frontend and backend, so you can define your API first and then build outward from there. This makes full-stack development a breeze. If you're working on a solo project and you're not sure if GraphQL is right for you, I would say definitely give it a shot. As with anything it takes a bit to really figure it out in your brain, but once you do, you wont regret it or ever want to look back.
• EugeneOZ 6y ago
  > But there's a catch. You have to build a BFF for each individual frontend. Bullshit. I've built a lot of REST APIs and every time mobile apps were reusing API without any issues.
• EugeneOZ 6y ago
  GraphQL should die in the same hell with SOAP. For me 3 reasons "why not GraphQL" are: 1) Access control: rights, permissions, roles - they are just a fog when client can write own query to DB. 2) Knowledge sharing: when your client knows too much about DB, you have a very tight coupling. 3) Complexity of the service layer. If there is no tool for the language you love - write your own GraphQL library. And there is no guarantee that your other client will be able to reuse this API.
• karmakaze 6y ago
  My takeaways from the article, use GraphQL for modern webapps: > Users expect an experience as native as it could be from websites. The Jamstack is taking over on the frontend. Hybrid models with server side rendering and dynamic Javascript clients are the enablers of these applications. RESTful APIs excel at a different set of problems. They will not go away, quite the opposite! They’re just not the right tool for this style of applications the industry is currently shifting towards. ...and REST or RPC for anything else. > I think REST APIs are a perfect tool for internal APIs, partner APIs and server to server communication. This is an area where GraphQL doesn’t really bring any benefits over REST. Alongside RPC it will have a great future in this area. GraphQL on the other hand is more than happy to wrap resource- and RPC-based APIs.
• z3t4 6y ago
  I like to use plain JSON rather then GraphQL, can anyone explain why you would use GraphQL rather then just JSON? Is JSON too low level ?
• AsyncAwait 6y ago
  Am curious how well is GraphQL supported outside the JavaScript ecosystem. I know there are various unofficial libraries, but it seems that gRPC has far better official support for non-JS/non-Node ecosystems.
• rey5137 6y ago
  For me, GraphQL is great tool but it take a lot of effort to migrate in case you already has a full REST API set. So, I choose a different approach, that is introducing a Batch Request API. Client can execute several requests with single network call and only get back a part of response they care about. With a small lib I wrote & full REST API set, you have pretty much all GraphQL function.
• sizt 6y ago
  first of all it's not a graph
• ezekiel68 6y ago
  From my viewpoint, GraphQL is yet another great battle in the never-ending saga between the "full stack" crowd and the "client vs server" crowd. This battle has been raging since WAY before Web 2.0 and SPA -- at least as far back as Susan in accounting sneaking in a DOS PC running Visicalc and Word Perfect instead of using the mainframe. It is so seductive to imagine that "opening up the back end" is the answer. But, as many here have pointed out, unfettered access to the data model and transactions leads (yes) inevitably to the kinds of ad-hoc interactions which no back-end can rapidly adapt to. Kind of. It doesn't rapdily adapt mainly because the server team doesn't want to be dominated in the organization by the whims of Marketing and the client team. This leads client team to demand fuller access, because it is tired of its creativity and velocity getting dragged down by the slow roll of the server team. Throw in an occasional economic downturn with pressure from management to rein in back-end costs and this becomes a drama truly worthy of popcorn-munching.
• raarts 6y ago
  Scanning through the threads here it strikes me that nobody mentions the (IMHO) biggest advantage of GraphQL: subscriptions. Something which cannot be done with REST at all, but hugely improves the user experience by keeping your screen up-to-date at all times. This also caters to the increasing event-orientedness of programming in general. Regardless of REST vs GraphQL API design issues this is the main reason I use GraphQL. (Side note: does anybody know why Apollo recommends using the websocket driver for subscriptions only?)
  • dalu 6y ago
    I don't use GraphQL and I have subscriptions or real time updates as well. On the backend whenever I do a equivalent of INSERT, UPDATE, DELETE I send a message over a websocket connection out to the connected clients. The client sends it's context whenever that changes so that the client only receives the necessary updates. I don't need GraphQL for that and I know what my code does, but with GraphQL I don't. I use Go on the server side and Angular or Flutter on the client side.
  • jensneuse 6y ago
    Good point! I don't yet see many people using subscriptions. Would be interesting to know what the blockers are. On the other hand there's the AsyncAPI specification which is also a good alternative.
• svilen_dobrev 6y ago
  comeon, like someone said below, GraphQL is just newest Corba/SOAP thing. A language to define interfaces, i.e. contracts. Whatever you make of them or with them. And whatever you make your server do on them. How well you do it, is.. up to you. Languages and making them are extremely powerful tools, ehm, if you master them. And in any case, one can abuse any thing, by lazyness or by misunderstanding, and grind it into snailing or halt. Anything. Here, defining and implementing something like graphcool exposing interesting part of (django) query-ORM into a simple language, took about 3-4k lines server side, +under 1k client-side, mostly utility stuff. Except graphene/graphql/django on python on server, nothing else is needed. Zero libraries in client. And now one can talk in that "language" in client, not worry about what server thinks of it, and/or switch the server into another platform/language any time - the contract is defined..
• dalu 6y ago
  How is a single endpoint for all queries a good idea from both front and back end perspectives? How is writing queries in the front end and exposing those queries a good idea? How is exposing the back end data structures a good idea? GraphQL is bad. You increase transparency on the client side and decrease maintainability on the server side. It's the worst of both worlds. I don't understand how people are advocating it, but then again you know how it goes, "eat more shit, millions of flies can't be wrong" Plus now you have to learn yet another query language.
  • valenterry 6y ago
    > How is a single endpoint for all queries a good idea from both front and back end perspectives Trying to project complex queries into a list of flat strings (path) is just not good. Having a standardized query language is much better. > How is writing queries in the front end and exposing those queries a good idea It's better than making x technical requests for one semantic requests because it's easier to keep track of what is requested and what is just correlated by time. > How is exposing the back end data structures a good idea? If you do that with either REST or GraphQL you are either doing it wrong or you care about speed a lot and generate your graphQL from your backend structures. GraphQL is especially nice if you have one backend and one or two frontends that you control.
• htkibar 6y ago
  BFFs needing security is not that valid; especially if you go at it as a "middle layer that queries things like your client would" and treat it from security perspective the same as your clients. (i.e. don't trust the bff) GraphQL does not have the same level of complexity as Docker; nor is it as obscure. With the libraries like apollo; especially if you have a "component driven" approach; being able to craft components as truly self-contained modules is quite freeing. Could you do this with REST? Probably. However with GraphQL managing the complexity of it is easier. This type of an argument could also be made for SOAP; since you could probably implement something like this there too. With GraphQL somebody already did that for me though; so I can just use it. I don't have to worry about creating multiple endpoints for my use cases; I only need to worry about specific entities and how to fetch them. I no longer need to worry about whether or not I am batching my queries etc because it is managed for me. This allows me to have (to the greatest extent) plug-and-play components that I can just chuck into places.
• hultner 6y ago
  I mostly prefer REST with OpenApi-schemas over GraphQL when building APIs but the one thing I really miss with that approach isn't something related to the technology in itself but rather the Apollo Client tooling around it. I've yet to find something that handles caching, updating of cached objects in such a easy way for OpenApi, it should be possible considering that a well documented schema contain the necessary information, but I haven't seen it.