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.
Facebook’s GraphQL gets its own open-source foundation
81–90 of 94 posts
Re: Facebook’s GraphQL gets its own open-source foundation
#82Earlier quoted context omitted.
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…
> 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 Well then you haven't really looked :) https://join-monster.readthedocs.io/en/latest/ https://github.com/graphile/postgraphile https://www.prisma.io/ https://subzero.cloud/ These are all examples of tools/libs that implement a graphql api without a N+1 issue
We at Hasura[0] use a GraphQL to SQL compiler approach[1] so its just ONE query no matter the size of the Graphql query.
[0] https://hasura.io [1] https://blog.hasura.io/architecture-of-a-high-performance-gr...
Re: Facebook’s GraphQL gets its own open-source foundation
#83I 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.…
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…
Facebook released DataLoader [1] to help reduce the number of database invocations. As long as you write your queries to fit the loader pattern it's pretty straight forward. Been trying out a golang port [2] for a month or two and it really (really!) improves performance.
[1] https://github.com/facebook/dataloader [2] https://github.com/graph-gophers/dataloader
Re: Facebook’s GraphQL gets its own open-source foundation
#84Earlier quoted context omitted.
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…
> 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 Well then you haven't really looked :) https://join-monster.readthedocs.io/en/latest/ https://github.com/graphile/postgraphile https://www.prisma.io/ https://subzero.cloud/ These are all examples of tools/libs that implement a graphql api without a N+1 issue
Those are great resources. But all of them appear to be tightly coupled with a SQL storage backend. That's valuable, but what I believe the ecosystem needs is a generic system which can "pre-compile" a GraphQL query into a backend language data structure which the developer can then transpose into a database query.
I think Facebook's Dataloader is more close to a solution.
Re: Facebook’s GraphQL gets its own open-source foundation
#85I 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.…
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.
I'm not entirely sure I agree that it shifts complexity. I think there's more complexity on both the client and the server end. I work extensively with GraphQL on the client end (iOS) and there's certainly more work involved compared to a REST endpoint for more larger applications. Notably:
* The mapping of the response to the types used in your app balloons. There's heavy use of Swift's Codable to map the JSON result to objects. I'm finding in a lot of cases where I'd be making queries and I don't need the resultant root object but rather a value one or two levels deeper. This has caused me to write a number of "shell" types to help streamline the decoding process.
* Different GraphQL requests can query for different fields on the same type, thus forcing your app to have to different types for arguably the same thing or have optional fields in more places that I would like.
* There's security implications with exposing your backend to any kind of request. GraphQL supports hashed queries so that the entire request isn't sent over each time and prevent the abuse that can result from an exposed API. Setting up and supporting this infrastructure takes some amount of resources.
* More complex to provide response metadata, such as cache control and request/response IDs. Granted, some of this could/should be moved to the response header but more complex types are trickier to handle.
That all being said, I'm quite happy with the trade offs compared to using REST, including:
* With REST, some of the endpoints ended up returning massive results as they had to support Android, iOS, and Web use cases. It's really hard to audit what fields were still in use by the app and the ROI on cleaning up the endpoints was minimal.
* Related to the above, it's easier to deprecate certain fields and make the changes on all the platforms appropriately. Given that GraphQL supports tracing of queries/fields usage, it's a lot easier to know when a field is no longer in use and be able to clean it up. Granted, this is more of a backend plus vs a client but it provides a much more smoother migration process for the client.
* Explicit declaration of non-null fields. Fantastic for mapping types. The entire GraphQL query fails if a resolver returns null for a non-null-defined field, giving the app a piece of mind with regards to type safety.
I agree there's definitely a short-term cost but a big ROI.
Re: Facebook’s GraphQL gets its own open-source foundation
#86Are there good alternatives to Apollo at all?
I made a chart of the download counts of the alternatives :D
https://npmcharts.com/compare/react-apollo,react-relay,urql,...
Re: Facebook’s GraphQL gets its own open-source foundation
#87Earlier quoted context omitted.
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.
>When comparing apples to apples, GraphQL is amazing for rapidly iterating. Rapidly iterating what?
Mostly the frontend. I’m comparing to a React+Redux+REST app where for every new resource you have to:
- create a new action - turn that action into requests via some middleware - denornalize and put in your store - maybe write a selector to get the data you need from your store
Re: Facebook’s GraphQL gets its own open-source foundation
#88Earlier quoted context omitted.
> 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 Well then you haven't really looked :) https://join-monster.readthedocs.io/en/latest/ https://github.com/graphile/postgraphile https://www.prisma.io/ https://subzero.cloud/ These are all examples of tools/libs that implement a graphql api without a N+1 issue
Those are great resources. But all of them appear to be tightly coupled with a SQL storage backend. That's valuable, but what I believe the ecosystem needs is a generic system which can "pre-compile" a GraphQL query into a backend language data structure which the developer can then transpose into a database query. I think Facebook's Dataloader is more close to a solution.
PostGraphile is built on Graphile Engine which is completely backend-independent (like GraphQL itself). This is what we use in PostGraphile for the "look-ahead" functionality, allowing you to build a database/API/backend query that represents a full GraphQL query as one action. You can read more about it here, though it's currently not as well documented as PostGraphile itself. https://www.graphile.org/graphile-build/
Re: Facebook’s GraphQL gets its own open-source foundation
#89I 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.…
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.
Re: Facebook’s GraphQL gets its own open-source foundation
#90Earlier quoted context omitted.
Can you elaborate why SPARQL is the wrong tech?
As someone who used to write SPARQL queries for a living with some of the most established players in the Semantic Web game, the idea of SPARQL and GraphQL serving the same purpose is pure misconception (usually by folks who haven't yet taken the dive into GraphQL). GraphQL allows the backend to say "here's the data I offer and how it's structured, pick which fields you want from that" and the frontend query just spe…
SPARQL results DO have an inherent structure. Even more, this is why projects like Eclipse Lyo can automatically convert SPARQL results directly to Java Objects. So no, SPARQL it is not intended to be used directly but as a product for a library to be converted into objects or rows or graphs or anything the client needs.
On the other hand, GraphQL pushes its complexity (to worry about the "how") into the server's implementation. The complexity is still there. And it's impossible to be automatically browseable.
Semantic Web is only an application of SPARQL, not the only one.