19 ms·

GraphQL is a great experience when you consume it and the service fulfills your query needs. Because you just ask stuff and you get them. It's really cool. On

• Calamitous 4y ago
  100% this. Folks see the cleanliness and simplicity of the front end without realizing the mountainous costs on the back.
• bennyp101 4y ago
  So much this - as a consumer it is wonderful, but implementing your own is ... fun.
• nine_zeros 4y ago
  GraphQL is great for consumers, it's a nightmare for producers.
  • alisonatwork 4y ago
    I think this is solved by creating "full stack" teams where the front end developers who want the GraphQL API are also the same team who define the schema and build the service that serves that API. In large companies where GraphQL makes sense, that GraphQL API service would just call into pre-existing services that serve JSON, Protobuf etc maintained by 100% back end teams.
    • nine_zeros 4y ago
      Forming full stack teams doesn't remove the pain of having to build the producer api in the first place. It merely shifts the burden from a backend only team to a full stack team.
• travisd 4y ago
  I’ve found it easiest to implement in Node due to the explicit event loop structure. You use data loaders, which is a super generic term that means “batch all requests for this resource into the next event loop tick.” So when a query requests a list of users, and then every users friends, that becomes two queries: one to load all the users, and one to load all the friends for all those users. The net effect is that your number of queries is O(query depth) rather than O(objects requested). Admittedly this does tend to work best with more K-V oriented data that truly relational data, and might be hard to retrofit onto a brownfield project, but i’ve never found it all that hard to do.
  • lexx 4y ago
    I've found that this is a simple and effective way to handle relational data either in REST or Graphql. But imagine having to traverse trees, filter on data of different types and levels. Sort and filter on edges. I mean it can get pretty complex and I am not saying that REST would be easier on those complex cases. In my opinion graphql and rest can both be super cute in simple everyday queries. But I am thinking that people are creating databases like postgres, mongodb, neo4j, etc, are doing exactly that. Trying to give us the power to query our data efficiently. Why not be able to expose directly the database and just add a layer for security, control, decorating and other stuff that would add value. Why rewrite databases?
    • travisd 4y ago
      There are products that do that! Hasura comes to mind. But APIs can have different use cases. It’s usually considered bad to directly expose your table schema over GraphQL because it locks you in and makes it hard to change your data model over time. And not all API access is “get this data” and “set this data” — it can be difficult to express complex logic in just a database. And of course, some GraphQL APIs aren’t backed by a database - they’re backed by other services (a la the “backend for frontend” pattern). I’m very pro choosing the simplest solution that works — but sometimes, the simplest solution does bring some complexity in exchange for other trade offs (like flexibility).
      • 4y ago
• PaulHoule 4y ago
  That's what you get for GraphQL not having an algebra. If it had an algebra you could build a database engine that answers GraphQL queries like a conventional database engine or you could write a general purpose schema mapping and some tool would write the code that converts GraphQL queries to SQL queries or some other language. As it is, GraphQL provides a grammar that looks like something people want to believe in but behind it all is a whole lot of nothing.
  • mumblemumble 4y ago
    This seems like a "be careful what you wish for" situation. Sure, you could set up an algebra that allows you to handle arbitrary queries for zero extra programmer effort, just like a SQL database engine does. And then you could even expose it to users, and let them execute arbitrary queries. And then, later, after you're done cleaning the molten slag off the server room floor, you could stop and reflect on whether that was really such a necessary thing to do.
    • PaulHoule 4y ago
      If you had a rigorously defined system you could put rigorous limits on it. If it's not rigorously defined there are no limits, just what people can get away with. With GraphQL you get the worst of both worlds that people can't write arbitrary queries but they can still trash the system. At least with undefined semantics people don't need to argue about whether or not they got the right answers.
      • ryanbrunner 4y ago
        "Rigorous limits" for a sufficiently large database means "uses our hand-picked indexes effectively", which reduces down to "provides the same functionality as a REST API" since you need basically a whitelisted list of acceptable operations. At best you can reduce transfer time by limiting columns returned, which is something but not really worth the added complexity.
        • 4y ago
• hirundo 4y ago
  I spend about 3/4 of a full time job building, maintaining and improving a corporate GraphQL API, and have for the last few years. What you are describing is not my experience. In fact it is far easier than it was in the old days when each new requirement meant code changes to a REST API. Certainly there have been problems with queries that had unacceptable performance, even those that took down the whole API server and database. Of course that wasn't a novelty with our REST APIs either. It certainly is an issue with GraphQL, but it has been a managable one for us. Largely this is because the API is not public, and it doesn't have to simply handle anything that is thrown at it. When we see a frequent, slow GraphQL query in a report, we have many options to deal with it, including going to the front-end team and asking them to query in another way, and I have had to resort to that. Often I can optimize the code instead. But that hasn't been a huge problem, especially compared to the great benefits of pushing most of the data work to the front-end. And the size and complexity limitations we've built into the API handle such problems seemlessly most of the time. The caller gets a clear error message that specifies the problem, and they can usually compensate very quickly with an altered query. When they can't then I get involved and sometimes have to say, uh, we can't do that ... without scads of extra work. And the work on my plate today is for one of those scads. I was doing lots of REST API work before GraphQL APIs, and my own and our corporate experience is that GraphQL solves a lot more problems than it causes.
  • frosted-flakes 4y ago
    > Largely this is because the API is not public, and it doesn't have to simply handle anything that is thrown at it. I think this is the key point.
    • Aeolun 4y ago
      Can’t you just have a gql query abort the moment it takes too much time to retrieve the requested data?
      • Kaze404 4y ago
        You can. There's the concept of query complexity as well that lets you simply reject queries that are too complex and likely to cause trouble.
• masklinn 4y ago
  > GraphQL is a great experience when you consume it and the service fulfills your query needs. Because you just ask stuff and you get them. It's really cool. I guess it's better when the tooling you use has direct gql integration and builds the queries for you? Because in my experience accessing the github APIs with "basic" HTTP libraries is way more annoying using v4 (graphql) than v3 ("rest") — it could also be that github's v4 API is dreadful mind, I wouldn't be surprised. GQL should be more efficient because it's not returning 95% of garbage I don't need, but having to write 5-deep queries (because of the edge indirections) by hand is way more of a pain in the ass than performing two GET requests with a few parameters munged in the URLs. And then I still have to go and retrieve the information 5-deep in the resulting document. Pagination is also awkward, because now you probably want multiple different queries (and thus multiple different resulting documents) so that your 2+ fetches don't retrieve unpaginated information you got the first time around. And it gets worse when nesting comes in. I don't think graphql is generally a great experience when you consume it either.
  • searchableguy 4y ago
    > Pagination is also awkward, because now you probably want multiple different queries (and thus multiple different resulting documents) so that your 2+ fetches don't retrieve unpaginated information you got the first time around. And it gets worse when nesting comes in. You don't need to write a different graphql query, use variables. Good graphql APIs will expose a start and limit field for Pagination.
    • masklinn 4y ago
      I think you misunderstood the issue. Of course you will use variables for the pagination itself, the issue is that your head of line query will be grabbing other fields than the paginated one. You don't want to repeat these fetches in the followup queries, they're redundant, and assuming the API is rate-limited they will decrease your query budget for no value. That counts double if you're fetching multiple paginated fields (which also adds to the awkwardness).
      • 4y ago
• claytonjy 4y ago
  To what extent does this headache go away if autogenerating graphql from a relational db, using tools like Postgraphile or Hasura? I never considered making my "own" graphql service but those tools sure make it look easy to create a nice API controller through db migrations.
  • sebmellen 4y ago
    We have had a wonderful experience with https://prisma.io https://prisma.io
    • o_m 4y ago
      Prisma only queries your own database. A GraphQL API could talk to many services and give the consumer one endpoint which all of this can be queried.
      • sebmellen 4y ago
        About 90% of our GraphQL API passes through Prisma. We have a master API that talks to many different microservices to process data and so-on, but all the data ultimately ends up residing in our Postgres DB. One of the nice things about Prisma is that it gives you a very declarative way to manage your data, and encourages using your DB as your "single source of truth". Querying everything through one API (which relays requests to other microservices, if necessary) and having one Postgres DB which acts as the "endpoint" for all of our data is a very clean model. For edge cases, it's also possible to write custom resolvers. Prisma doesn't prohibit that.
        • alisonatwork 4y ago
          Philosophically, is it really a "microservice" if it doesn't have its own database? In my opinion, if multiple services are ultimately all connecting to and storing their data in the same database, then you haven't really gained very much, since one misbehaving client can still take down everyone else's service. The point of microservices was always sold to me as "every team owns their own stack", and specifically if one team's stack goes down, everyone else can cheerfully continue. (Or less cheerfully, if the team whose stack went down was identity or user service.)
• deleted 4y ago
  [deleted]
• rlili 4y ago
  Unless you happen to be using PostgreSQL, in which case some tools like Hasura and Graphile can automate all of that.
  • deleted 4y ago
    [deleted]
  • criddell 4y ago
    I’ve never used those tools, but I don’t see how you can automate away authorization issues. The GraphQL spec[1] says authorization in the GraphQL layer is fine for prototyping or toy programs, but for a production system it needs to be in the business logic layer. [1]: https://graphql.org/learn/authorization/ https://graphql.org/learn/authorization/
    • gavinray 4y ago
      In Hasura, you authenticate externally -- can be custom API endpoint that signs a JWT/auth webhook, or an auth provider like Auth0, Okta, Firebase, Keycloak, etc. Doesn't matter, just have to return some claims values. You can then use these claims values in your authorization (permissions) layer. IE, when a user logs in, you can sign a claim with "X-Hasura-User-ID" = 1, and "X-Hasura-Org-ID" = 5, and then put rules on tables like: > "Role USER can SELECT rows in table 'user' WHEN X-Hasura-User-ID = user.id" > "Role USER can SELECT rows in table 'organization' WHEN X-Hasura-Org-Id = organization.id" There's more depth to it than this, but this is the gist of it.
      • pycal 4y ago
        this is really powerful stuff when working with a CISO “the data itself defines who may access it”
    • golergka 4y ago
      You just handle this part my your code and leave the rest to Hasura.
    • RedShift1 4y ago
• jseban 4y ago
  > GraphQL is a great experience when you consume it and the service fulfills your query needs. Unless you already know SQL, and you realise how small and simple the queries could be, then it's really not a great experience to be forced to use graphql.
  • papito 4y ago
    Hell yes. Good knowledge of SQL is a superpower and is becoming a rare art form. The new generation of devs thinks that frameworks and ORMs will do the magic for them at no cost, but they don't. There is no substitute for leveraging your storage engine to the max. The sad part is that databases have evolved and became much better in the last 20 years (I started with MySQL 3.x), but we just don't use them. Everyone acts like "microservices" solved all of our technical challenges. Right.
    • jimbokun 4y ago
      In my opinion, the value of a well architected micro service is to figure out how to optimize and leverage the capabilities of the underlying storage engine, while presenting a simple performant and correct API to consumers, while not requiring those consumers to understand the underlying details of the datastore.
      • papito 4y ago
        I am not talking about the customers. Of course they are not supposed to understand it. I am talking about the system design. And microservices do not solve problems in most companies, just create new ones. Distributed systems did not magically become simpler to reason about just because there is Docker.
    • KptMarchewa 4y ago
      It's "previous" generation of devs that build Hibernates and Entity Frameworks and other ORMs. I work with "data" systems, where everything has been migrating in the other direction - to SQL - from custom code for last 5 years or more.
    • 4y ago
• arinlen 4y ago
  > GraphQL is a great experience when you consume it and the service fulfills your query needs. Because you just ask stuff and you get them. It's really cool. How about caching? It feels like GraphQL tries to win some (arguable) flexibility in putting together clients and in the process throws out most of the operational advantages of resource-based APIs with significant disadvantages in both how to put together a backend.
  • RedShift1 4y ago
    You can execute GraphQL queries via GET and set a cache up for it like REST. Technically it's also allowed to cache POST requests but I guess anyone who comes across that is going to raise their eyebrows.
    • arinlen 4y ago
      > You can execute GraphQL queries via GET and set a cache up for it like REST. Does it, though? It seems it really doesn't, nor was GraphQL designed with HTTP caching in mind. The only references to caching in GraphQL are vague hand-waiving arguments about how theoretically GraphQL implementations might be implemented with some sort of support for caching primary keys. But any type of HTTP caching is automatically excluded from GrahQL. To put it differently, is there any third-party caching solution for GraphQL? As far as I could gather, the answer is no.
      • RedShift1 4y ago
        It looks like you are fixated on caching in GraphQL, but that's unnecessary, you can just cache GraphQL like REST, because in the end they are just GET requests. Just cache the GET request.
        • arinlen 4y ago
          > It looks like you are fixated on caching in GraphQL, but that's unnecessary Oh so one of the most basic feature of any API, one which has a direct impact on scalability and motivates entire product lines and businesses like CDNs, is now "unnecessary"? > you can just cache GraphQL like REST, Go ahead and show one example, please.
• didip 4y ago
  I am with you. Every time I looked at GraphQL or asked to implement one, I had to say no. How is this a good thing for the backend or infra engineers? It's a mega facade without a lot of toolings to help the backend. GraphQL reminded me of common ORM criticisms. Wide API surface area with a lot of rooms for accidents. And GraphQL made it worse by being exposed as a service.
  • sailfast 4y ago
    It’s not, really, but it IS a good thing for feature development speed if that’s what you’re into, and might help a team figure out quickly which data is critical to optimize for once you start putting more serious data loads through your APIs?
  • brentm 4y ago
    100% - I can see how it might be great for FB where they have the capacity to optimize but without that engineering capacity it seems like it would turn into a net negative.
  • ehutch79 4y ago
    No one sees the backend. So who cares? /s With ORMs at least, the developer is likely either thinking about limitations, or really needs the guide-rails an ORM provides. I doubt a lot of front end engineers, many of which probably have never optimized a DB, are thinking about the consequences of their queries.
    • dustymcp 4y ago
      I can say for sure this is the case
    • freedomben 4y ago
      what you say is unpopular, but it's a lot more true than most people (especially front end people in this case) want to admit. Of course there are plenty of exceptions (people on FE who think about, care about, and know about what happens on the backend), particularly the Venn diagram of FE people reading HN, but the majority in the industry definitely do not. The bigger and/or more specialized the company, the worse that problem gets. To be clear, this is not just a problem for FE people. extremely normal for humans to become myopic in the areas they spend the most time in. FE does it, BE does it, management does it, everyone does it. Find a standard mobile engineer doing native iOS or Android, and they're going to be even more disconnected from the effects on the backend, and they come by it honestly. If you tend to specialize more in one area, building an awareness of your own biases/perspective, and exercising intentional empathy, can make a huge difference in how easy you are to work with. When looking at dysfunctional engineering orgs, one of the first things I do is figure out where the "power" is and figure out their backgrounds. The most extreme example might be a company founded by a FE eng for whom backend is just a necessarily evil to support their app. Or a company founded by a BE guy for whom the real value is the API, and the clients are just there to abstract it for normal people. Taking this in and finding a healthy balance of the way things are structured can help improve a dysfunctional org a lot. FE, BE, DevOps/Infra, etc are important pieces in an overall puzzle. Without a well-functioning team behind each, the company and product suffer.
• golergka 4y ago
  Have you tried Hasura?
• sixdimensional 4y ago
  I worked in the data federation space for a number of years (it's actually quite an old term, I worked in it back in 2013, around the time there was an early wave of activity around this and the concept of a "data fabric"). When I saw GraphQL come out, I knew that what you are saying would happen. In the data federation tool I worked in, SQL was the interface abstraction to join across heterogenous platforms (think of things like Presto/Trino or Dremio). GraphQL as an interface requires the same underlying infrastructure as that data federation tool I worked on in terms of query analysis, parsing, planning, optimization, execution, etc. Those are "hard problems" due to lack of standardized interfaces, access patterns, direct data access, I/O, network bandwidth and infra related latency, costs, compatibility, data types, etc. These problems are distributed system problems coupled with often incompatible interface layers (e.g., even if you are using multiple SQL databases with GraphQL, you run into the same). If your scale is such that you can build GraphQL on a handful of systems and for a handful of use cases, great! If you have to go to a certain larger scale, you're back into federation territory (which in the app layer might also be called API composition). One potential option - when you reach the point where you need complex GraphQL query coordination, more than seems to make sense to implement, pair it with a data federation tool such as Presto/Trino, Dremio, Denodo, or research approaches such as caching/materialized views (engines like that are becoming decoupled from databases, such as Materialize.io) - and let those engines do the hard work. In that case your work becomes more like GraphQL -> SQL or API -> a data federation, caching or materialization platform. CQRS and event sourcing plays a role here too. Consider also, the possibility that if you are willing to accept a bit of delay in aggregated results from multiple systems, doing those compositions or aggregations in the data platform layer, and simple feeding those to the GraphQL interface. That could even be done in a single database/data platform if you really wanted without too much fancy federation tech. Federation is powerful but complex. It seems like a fun hard problem, but for many tech teams, it can be a complexity and time suck. My recommendation would be try to avoid building that if you can.
  • captaincaveman 4y ago
    A good summary, and similar to my own experience.
• taeric 4y ago
  This seems to echo SQL. It is amazing. You have to be mindful of how much effort a query will take. And very careful.
• valenterry 4y ago
  There's nothing that stops you from exposing only what you would expose in a "restful" API. You can even specify the exact queries that can be used by the client. And even then GraphQL gives some nice advantages, such as introspection and endpoint discovery, as well as smoother error handling and increased type-safety.
• coffeefirst 4y ago
  The flip side of this is a lot of folks are adopting GraphQL who are not prepared to do it well, so they make something half baked, missing things you need, and their documentation is absolutely useless. This isn't new, there's plenty of sloppy REST APIs, but it was so much easier and less painful to explore and stitch together pieces of an imperfect REST API than it is to interact with a bad GraphQL API.
• est 4y ago
  > it feels like writing your own database. You have to create a query plan, handle optimizations, corner cases, etc. The culprit is "micro" services. The whole thing was invented by a "software consulting" firm to milk as much billable hours as possible to make a system over-engineered and costy to support but easy to split into multi-layer/multi-stage outsourcing teams/phases, the industry fail into this stupid trap, and the burden was shifted into web & mobile clients, the next thing they realize is sometimes they have to make queries inside while loops. If your data can be "planed" or "optimized" via a single centralized "GraphQL gateway", then it probably can be centralized inside a single database transaction call with so-out-of-date-you-should-never-use JOINs. I recently had to render a user feed page, query uid for fids then fid with cmt-ids then each cmt-id for uids for avatar/nick and such, all from a stupid user profile lookup "micro" service, provided by another department, which only accept one param per query (spoiler alert: it's an "anti-pattern", but a sweet "optimization goals" for your next "sprint milestone"), I had to carefully and cleverly combine all those data needed make them as parallel lookups in async with a very good re-usable batch loader class. Which makes me wonder, if all those data sits right inside the same db, why bother scatter them into so many service pipes, then gather them in an PITA fashion? As a developer I am not against GraphQL or Microservices because it pays, and it's a good pile of tech jargon to confuse the non-tech people and it really sticks, but from a pure technical point of view it's a waste of cpu0 power and emits needless CO2.
  • alisonatwork 4y ago
    Although the microservices terminology might have been invented by a software consulting firm, distributed architecture already existed and solved problems for many large companies that needed to scale their products (and development processes) beyond what a small team hitting a single database could achieve. However, I think that's the key point to keep in mind when considering whether GraphQL is a good fit - if you don't already have multiple domain-specific services in your infrastructure, then adding a GraphQL gateway service doesn't make a huge amount of sense to me, because you could've just had your small team of front end developers talk to your small team of back end developers to create exactly the optimized endpoints they needed to solve the problem. To me GraphQL really seems like a solution for an organizational problem, where there are dozens of teams who all maintain their own services and apps, and now a variety of front end teams want to combine different sets of data from services maintained by different sets of back end teams in a way that doesn't have alignment across the company as as far as deployment/release schedules go... Well now it makes sense to construct a flexible API schema maintained by and for front end specialists - it's just moving their already-existing data processing/join logic out of their various clients into a common server-side component.
• pkulak 4y ago
  Hmm.. that hasn't been my experience at all. I wrote the public GraphQL API for my company, and it was a pretty straight-forward experience. Yes, I had to spend some time on the basic plumbing, but now if something needs to be added, it's just a matter of defining some interface for it and fetching when required. Grabbing an object from the network or DB doesn't need optimizations, a query plan, or have corner cases. Even grabbing i objects starting at offset j only adds a bit more busy work. Maybe the trick is to keep it simple? There's no need for a bi-directional graph or advanced filtering. But if there really is, it's not like sticking to REST would make that any easier. Some things are just hard, no matter the interface.
  • lexx 4y ago
    You are right. Some things are just hard. I went deep into Graphql because I wanted to explore the possibility of it being an more comprehensible interface for the end user in comparison to a REST interface. In such cases, it is not. Graphql gives a better way to request nested schemas and handle relationships and recursion. But when you cross that line, the client now would get ideas and starts asking "Why not be able to do that operation on the 5 level deep object?". Now you have to either not allow the client to do that, or you have to "rewrite the database" to make recursion optimal. This is not a problem of Graphql. This is an HTTP problem. When you need to promote the database querying layer over HTTP, then you have a problem regardless.
    • bitL 4y ago
      Try a nested pagination (i.e. open the 352nd page of the 7th book on the 3rd shelf in the 5th room of the 3rd city library. Make it performant. Have fun with GraphQL! /s
      • necovek 4y ago
        That sounds trivial I think because you are looking for exactly one item and there's no pagination involved. The problem might be to get those 352nd pages of every book with the title starting with "A" sitting on 3rd shelf of every city library: when there are unbounded results nested deeper than top-level, and possibly those multiple times, that's when it gets hairy.
• 88913527 4y ago
  Filtering on relationships is a big issue for us. Each nested node in the query graph (tree?) generates a new SQL query. We seem to committed to that approach at this point, to trying and migrate to a world where we inspect the whole thing, then make 1 query, isn't going to happen.
  • pycal 4y ago
    i know relationships don’t typically have props in a store like neo4j, and moreover you can reproduce that in something like postgres with a foreign key we had a challenge like what you describe though, and were able to avoid new queries by representing the relationships as objects. in so doing, we leverage row level security and jwt claims, which is an approach to authorization which has high epistemical legibility.
  • yougotrioted 4y ago
    Not trying to specifically shill my own library, but I developed this a while ago before there were any established patterns with filtering on relationships in graphql. https://github.com/tandg-digital/objection-filter https://github.com/tandg-digital/objection-filter Out of curiosity, would functionality like this implemented in graphql solve your issues?
• abxytg 4y ago
  Every time I start with Graphql in surprised that I'm writing all the routes and middleware I'd need with with a restful api in express. I feel like I'm missing the point.
• alimov 4y ago
  > “On the other hand, when you are the one to implement the Graphql server, it feels like writing your own database. You have to create a query plan, handle optimizations, corner cases, etc.” Is this still true if the structure of the data is relatively simple, but you have tens of millions of users? Say the data that is returned (per user) has 20 or 30 properties in total (for each user), and you are only ever asking for specific data about an individual user.
  • cormacrelf 4y ago
    You have to do your own optimiser to avoid, for instance, the N+1 query problem. (Just Google that, plenty of explanations around.) Many GraphQL frameworks have a “naive” subquery implementation that performs N individual subqueries. You either have to override this for each parent/child pairing, or bolt something on the back to delay all the “SELECT * FROM tbl_subquery WHERE id = ?” operations and convert them into one “… WHERE id IN (…)”. Sounds like a great use of your time. In the end you might think to yourself “why am I doing this, when my SQL database already has query optimisation?”. And it’s a fair question, you are onto it. Try one of those auto-GraphQL things instead. EdgeDB (https://edgedb.com https://edgedb.com) does it as we speak, runs atop Postgres. Save yourself the enormous effort if you’re only building a GraphQL API for a single RDBMS, and not as a façade for a cluster of microservices and databases and external requests. Or just nod to your boss and go back to what being a backend developer has always meant: laboriously building by hand completely ad hoc JSON versions of SQL RDBMS schemas, each terribly unhappy in its own way. In no way does doing it manually but presenting GraphQL deviate from this Sisyphean tradition. I read in the article that NOT having GraphQL exactly match your DB schema is a best practice. My response is “did a backend developer write this?” Sounds awfully convenient for job security!
    • alimov 4y ago
      Thank you for the response, I really appreciate it
    • aabbcc1241 4y ago
      If you're using embedded database like sqlite and lmdb, the N+1 query pattern may be less impactful to the performance
• dmitryminkovsky 4y ago
  This is why I wouldn't use GraphQL without something like Hasura, where a relational Db schema is used to automatically generate GraphQL and REST apis
  • alimov 4y ago
    Thank you, I’ll check it out
• lowwave 4y ago
  My experience using GraphQL is the same as using React. Look great at firs glance and it makes sense. Using it for a while and I realize it designed to be used by the fb team. For example, they are design for a large team to work on a small components separately. Most developers are NOT fb, thank goodness. There are better, fast and light weight alternatives for smaller or other kind of teams.
• cryptica 4y ago
  I think similarly. If you have control over the back end environment, it's not worth the extra effort, additional complexity (e.g. caching challenges) and performance overheads to run a GraphQL server.