Facebook’s GraphQL gets its own open-source foundation

[burtonator]

I did a huge heads down on GraphQL vs AppSync vs Firebase for an app I'm building around document collaboration, annotation and sync for people working with PDFs and web content (https://getpolarized.io/) - it's kind of like an offline web browser.... anyway.

GraphQL is super awesome at what it does but it's definitely not designed for rapid prototyping applications.

The thing about GraphQL is that it's middleware. It's designed to act as really nice glue between multiple backends.

It solves a lot of nice problems like over-fetching too much data, calling too many APIs, etc.

The problem is that you really don't need these to get an app shipped immediately.

The REAL sweet spot for GraphQL is for a company like Netflix or Facebook where you have 1500 APIs and tons of problems with data over-fetch and you have the time to sit down and do things right.

I think I'm going to end up going with Firebase just because you can bang something out FAST and get it shipped.

It's not going to be perfect but you can ship an MVP and start making revenue and/or grow your user base while you figure things out.

[013a]

GraphQL to REST is a more typical comparison. In this case: designing a GraphQL API is substantially easier to both make and consume; while REST just tells you "here's some guidelines, now go do it however you want", GraphQL enforces a much more consistent view of how an API should look, while allowing clients much more freedom in how they get the data they need.

Where you start running into issues is the surrounding tooling. Integrating a typical REST API into an APM monitoring solution is a cinch, because all of these tools know how to read the incoming requests, HTTP methods, paths, bodies, etc. With GraphQL, you might be left building glue for your APM tool of choice, or just using the highly limited, but at least specialized, Apollo Engine. Enforcing strict rate limiting is easy with REST; very difficult with GraphQL due to how complex and free-form queries are.

Optimizing your backend to support those free-form queries is also (I dare say intractably) difficult; I haven't seen a single backend framework which doesn't actively encourage an N+1 problem on any query which returns multiple objects of data. AppSync as well, my god is that an evil play from AWS; if you've got separate lambda functions serving all the different nodes in your graph, a single query could trigger dozens, or even hundreds, of invocations. Combine that with their guidance to use Aurora Serverless and any casual observer might say that they're actively exploiting the unfortunate ignorance of an engineer trying to jump on the latest trends.

I don't believe any of these things are problems with GraphQL. I think they're issues with ecosystem immaturity, and I hope they get better over time. Frankly, every single backend library I've used sucks; its designed to be awesome on the frontend, and it is.

I think you're right that, right now, its best suited to large organizations. Large organizations can engineer around all of its issues and extract a LOT of value from it. Medium organizations are almost immediately going to run into ecosystem immaturity and scaling issues. Small organizations are going to get the most value from an "all in one" solution, whether that's Firebase, or a simple REST API on App Engine, or something like that.

But I could be wrong in my analysis that its not a core issue with GraphQL, and there are subtle complexities with the API definition language which make scaling it for anyone who isn't Facebook intractable. Time will tell.

[cheriot]

GraphQL shifts complexity to the server instead of the client. That can be an advantage when there's multiple clients or just one client iterating faster than the underlying logic. There's certainly a short term cost to GraphQL compared to REST, but there's a lot of use cases with positive ROI outside FANGs.

When read and write becomes real time sync, though, I've always thought Firebase was under appreciated.

[jchb]

> tons of problems with data over-fetch

What is the GraphGL story on caching and closest point of presence redirection? We build a mobile app that consumes various "enterprisy" HTTP-based APIs. Often, due to how the APIs are designed to support a range of different frontends, we have to either fetch more data than we need, or do a bunch of granular requests where we would prefer to do a single large one. But most of the time that is outweighed by the fact that many responses are cached in CDN (Content Delivery Network). Since our users are spread out globally, going to the origin server for every response would in many cases imply a latency of 100-200 milliseconds, which wouldn't be acceptable.

[baby]

Agree with you, for small apps it looks like this is a lot of effort for little benefits. For large companies that deal with huge APIs, maybe it's good.

[cdaringe]

Hard disagree for many cases. GraphQL APIs are free with db reflection tools--ga ga ga ga GREAT for prototyping. Shoutout to postgraphile.

[hamandcheese]

GraphQL is not comparable to Firebase, it is comparable to implementing your own REST/gRPC/Thrift API.

When comparing apples to apples, GraphQL is amazing for rapidly iterating.

I think the biggest risk with GraphQL is it’s too easy to just mirror your data structures as an API.

Also, unrelated to the above, but we use Firebase for a few auxiliary real-time needs at work and it goes down constantly.

[k__]

Did you use AWS Amplify?

I had the impression it was like Firebase for quick prototypes (saw someone build a product in only 4h once), but you get CloudFormation templates out of it, which makes it much more flexible in the long run, when you customize more and more.

[ivanhoe]

Not necessarily, on small projects that are being rapidly developed it's very common that you need to change many times the data structures returned by api, as front-end is iterating on the design and ideas and figures out the new pieces of data that they need. Mapping the results of DB queries into complex structures & entities, and juggling it to fit the latest needs of front-end/app devs used to take a big chunk of my back-end dev time (and nerves). GraphQL can extremely simplify and speed up these iterations.

[davidjnelson]

You may also enjoy heroku for hosting an mvp. Pricy, but straightforward to scale and set up a staging env for testing release candidates on, plus lots of great features like automatic db backups. And since it’s built on aws it’s easier to shift some microservices onto ec2 later as needed.

[alwaysreading]

Totally agree. GraphQL makes perfect sense for a large app with many endpoints but there isn’t a lot of benefit for smaller apps. I’m involved in an app now that “has to use GraphQL” but could easily be done with a restful api without the additional overhead of what is essentially middleware.

[adamnemecek]

I think it’s dope if you are fundamentally querying a graph. Doing it manually is repetitive.

[orta]

As someone who knows a few of the folks involved in this foundation, I think this is a real net positive for everyone who builds GraphQL APIs and is involved in improving the ecosystem.

[xrd]

I remember when I was at RealNetworks a long time ago and Microsoft and Real were competing over the future of multimedia languages (SMIL vs HTML+Time). I was on some of the standardization committees and remember being surprised when some of my colleagues suggested that standardization was used by companies like MS to slow down the innovation process (and catch up to faster starts like RealNetworks had made). I wonder how often open source foundations serve the same purpose, or if these are truly embraced by companies like Facebook? Is there a reason internally Facebook would have fought something like this? Is it all roses?

[vjeux]

Lee Byron who was one of the founders of GraphQL and has been actively driving its success in Open Source left Facebook recently (after a very long tenure). Making GraphQL part of a foundation is likely a way for him to be able to keep stewarding the project. He wrote a post with a bit more context: https://medium.com/@leeb/introducing-the-graphql-foundation-...

[jahewson]

It’s common knowledge in the community that GraphQL already covers Facebook’s use cases and they’re wanting others to take up the reigns for new features, e.g. Apollo. A foundation puts all contributors on an even footing.

[joshred]

There's a little of column A, a little of column B.

Standards allow the information economy to function... but influential companies want their internal practices to become 'the standard'.

[k__]

It probably isn't all roses, but I have the feeling people today are more prone to "fork" if they feel belittled, because of the omnipresence of the Internet they feel less weak against big companies.

[syn0byte]

Generalization of Hanlen's razor: Never attribute to malice what can be explained by laziness/greed/stupidity.

FB has GraphQL stable and doing exactly what they want it to do. Now they can pass it off to a foundation for maintenance and blame without having to pay out of pocket.

[mohsen1]

Both Swagger (Open API Spec) and GraphQL are now part of the Linux Foundation! That's cool!

[jondubois]

I'm not a big fan of GraphQL. Its main benefit is for serverless which I am also not a fan of. It shifts all the control to the client and makes the server generic which actually takes away flexibility overall.

[LeicaLatte]

Are there good alternatives to Apollo at all?

[mxstbr]

There's lots of alternatives, but whether they are good or not depends on your use case:

- Relay by Facebook, it's own GraphQL client: https://facebook.github.io/relay/

- Urql by FormidableLabs, an effort to build a simple React GraphQL client that covers the 80% use case: https://github.com/FormidableLabs/urql

- GraphQL Request by Prisma, a minimal, universal GraphQL client: https://github.com/prisma/graphql-request

Plus a variety of smaller ones like Lokka (https://github.com/kadirahq/lokka), FetchQL (https://github.com/gucheen/fetchql) and micro-graphql-react (https://github.com/arackaf/micro-graphql-react).

It's all about the tradeoffs you want to make: if you're building a React app your can't go wrong with Relay or Urql, if you're writing one-off (universal) scripts graphql-request is probably your best choice, etc.

[cheapsteak]

I made a chart of the download counts of the alternatives :D

https://npmcharts.com/compare/react-apollo,react-relay,urql,...

[LeicaLatte]

Thanks for the recommendations.

I write native iOS and Apollo code generation can be quite hit and miss.

[andridk]

https://github.com/prisma/graphql-request

[tw1010]

Oh great, an ad that covers the entire page on mobile. Guess I'm not reading this article then.

[jmeyer2k]

I don't think they care if you read the article. They just care that you saw the ad.

[jen729w]

I didn’t want to start the meta-whine about the reading experience, but as you’ve been so kind, I’ll chip in.

I’m an Australian. I’m currently on holiday in Girona, Spain.

Holy shit how do you people deal with these cookie notices all day?! Techcrunch covers the entire screen with something you have to click [0], and it’s hardly alone.

This is insanity. Who was this meant to benefit?

[0]: https://share.icloud.com/photos/0KfvL5LoHln0FNLDqzrbdjRKg

[robert_tweed]

Better link:

https://gql.foundation/

[cenal]

Let’s make that content useful:

https://outline.com/7XDNDL

[nikhilsimha]

About time.

[beders]

N+1

[leddt]

DataLoader

[degyves]

Great. Another solution for an already-solved, already-standardized query API language (SPARQL).

[i_phish_cats]

SPARQL demands a certain data model (triple stores). Also, everything about it smells like ivory-tower academic snobbery + ultra-large-enterprise crap. GraphQL does neither.

[linkmotif]

You’re getting caught up in the “graph” part. GraphQL is unfortunately named, because it doesn’t actually have any “graph” related semantics or features in the graph database sense. The “graph” in GraphQL just refers to the fact that you can use it to retrieve nested data. On the other hand, SPARQL and Tinkerpop (the “true GraphQL” imo) are actually about graphs and related data in the graph database/semantic web sense. GraphQL and SPARQL have nothing to do with each other.

[hn_throwaway_99]

GraphQL is not a generic query API language. One of the most unfortunate things about GraphQL is the presence of "QL" in the name makes people think it is somehow comparable to SQL or SPARQL.

[marktani]

I recommend this talk to see what both technologies can still "learn" from each other - https://youtu.be/LUF7plExdv8. I don't think SPARQL or GraphQL completely replace one another.

[lsh]

Fellow curmudgeon, I give you an upvote. SPARQL is a more elegant tool from a more civilised time.

[atombender]

GraphQL isn't a query language, it's an API protocol language. Big difference.