15 ms·
The GraphQL stack: How everything fits together
- Hendrixer 9y agoI'd love to see some examples of a proper GraphQL gateway that consumes the cache control
- Svenstaro 9y agoHas anybody found a way to combine GraphQL and REST in a common API? I've searched but so far found no idiomatic ways to accomplish that. The reason I need REST in addition to GraphQL is that there are sometimes oddball cases where only GraphQL is a poor fit or where compatibility with older clients that I can't modify has to be ensured. Also, is there a good way to do file upload of big files with GraphQL nowadays?
- Hendrixer 9y agoWe have @ https://tipe.io https://tipe.io. you can use rest and GraphQL. Basically, given a REST url, you dynamically create on graphql query on your server, and the execute that query against your schema. It's all meta
- Svenstaro 9y agoWasn't able to find a library or a Github or anything like that from a quick glance. I'm assuming this is a closed platform. What I was inquiring about was something that I can use in my own software.
- slimsag 9y agoYou seem to have misunderstood the parent here. They are saying that at their company, they are doing this (_not_ as a library or product you can purchase). Parent was saying that to implement it, they essentially wrote their REST API by grabbing a URL, dynamically creating a GraphQL query for it on their backend server, and then executing that query against their own GraphQL schema and returning the result.
- nowarninglabel 9y agoWhy do you believe you need to combine them? We have a REST API and GraphQL API. They both work well for their respective use cases and together satisfy our needs.
- Svenstaro 9y agoI would like to present them to the user as "here is our API" as opposed to "here are our somewhat complementing APIs and for the one you use these docs and do this and for the other one there's the docs here and you use it differently."
- atomashpolskiy 9y agoWe're developing a REST framework, which lets the client to shape response on a predetermined and constrained set of endpoints on the server. The client can include/exclude parts of the data (attributes and relationships), set filters and request aggregation. You may take a look: http://linkrest.io http://linkrest.io
- colept 9y agoYou can use directives to retrieve a REST API through GraphQL. For example: https://github.com/n1ru4l/graphql-schema-generator-rest https://github.com/n1ru4l/graphql-schema-generator-rest
- cvburgess 9y agoDuring a Q&A at GraphQL Summit, GitHub said that they are accomplishing this by making their REST endpoints use the GraphQL API instead of querying the data directly. They’ve been releasing the talks online slowly so that should be available soon.
- cohen900 9y agoThat's sounds good..!
- marknadal 9y agoYou can get some of these benefits for free and today by using https://github.com/brysgo/graphql-gun https://github.com/brysgo/graphql-gun (disclaimer: I did not write this, but I am the author of the library it depends upon). 1. For instance, caching also happens on the client. This means if you reload the page, your GraphQL query will pull immediately from localStorage! 2. And then, quite important, it will be backfilled by the server with any new updates, including realtime updates that happen from other peers while the user is still using your app. Great work on the tracing and schema support pieces! Those are certainly handy features.
- jondubois 9y agoMy main concern with GraphQL is access control. What happens if the user doesn't have access to part of the requested data (a subtree)... Will the GraphQL engine return an incomplete result, an inline error or will the whole query fail? What if you only want to allow showing specific fields of a resource; for example when a user requests for another user's account details, we need a way to block them from getting certain fields like passwords or keys that might be attached to the account. How does this access control play with cache? What happens when the access control rules change? A while ago, I wrote a real-time REST-based plugin which solves all the problems and I use it in production, it's much simpler than GraphQL. See https://github.com/SocketCluster/sc-sample-inventory https://github.com/SocketCluster/sc-sample-inventory I'm surprised that more libraries aren't following the REST-based model.
- stingraycharles 9y agoWe let our GraphQL server accept a JWT authorization header, which is then propagated to all service calls it does. When the user doesn't have permission to some (sub)resources being requested, the GraphQL server doesn't see it either.
- k__ 9y agoBut what comes back? Lets say I request a user, his name, email and all their friends. But I don't have access to the friends. Now do I get nothing back and the error that my request would include data I have no access to? Or would I get name and email, but the list of friends would be empty? would I get an additional warning somewhere so I know it's an permission problem and the user doesn't have no friends? Would I get an inline error in the place of the friends?
- cheald 9y agoThat's entirely up to you and how you choose to implement your fields' resolutions.
- 9y ago
- d3ckard 9y agoCan anybody explain to me how it's solving any problems? The way I see it they only move the responsibility to combine data from client to server. At the same time, you now don't just expose a couple of endpoints, you need to support a query language, which seems to impose much more effort in things like authorization. I admit I don't see the benefit.
- sorenbs 9y agoMoving the responsibility of combining data to the server is a huge advantage for many organisations. It allows application developers to move much quicker and provides a common data access layer for all applications. It sounds to me like you are over-indexing on the burden placed on the backend developer in your evaluation and not considering the whole picture. From my experience, the biggest advantage of GraphQL is that having a well defined standard allows the community to build advanced tooling such as https://github.com/graphcool/graphql-playground https://github.com/graphcool/graphql-playground by Graphcool and all the cool stuff Sashko is talking about in this presentation.
- d3ckard 9y agoThat I understand. The problem is that on the way you basically reduce your server to the thin layer over DB. Exposing querying API means that you significantly lose control over what, where and how you provide from the server. We are currently considering using GraphQL in current project and I took a long look at both the standard and library (Absinthe for Elixir). It looks terrible to me. Basically you need to provide yet another layer, supporting mostly generic operations. If your action is more then CRUD, you still need a REST API. Moreover, you slowly lose control on what can be changed and where, your frontend basically eating logic, but unlikely to be working on it's own. I understand that it helps when you have records with multiple associations and you want to increase performance and not load everything everywhere, but the cost appears to be huge in terms of maintenance. I totally get why FB is doing it, but it seriously worries me that they market it as an successor to REST, instead of an alternative with such-and-such tradeoffs.
- 9y ago
- stuartaxelowen 9y agoWhy graphql instead of SQL with proper access control?
- elnygren 9y agoThis question does not make much sense: a GraphQL API can an often is implemented with SQL ! You could ask: why graphql instead of RESTful?
- guelo 9y agoOf course it makes sense. They're both query languages, right? Why is { project(name: "GraphQL") { tagline } } Better than select tagline from project where name = "GraphQL" Especially if the GraphQL server is just an intermediary later that ends up being translated to SQL anyway. That real answer to the parent's question is that most people don't have confidence in SQL servers's access controls.
- elnygren 9y agoIf you're proposing that web servers should not exist and we should just expose the SQL DB via HTTP: what about when you don't have all of your data in a single database? What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions. In fact, some people might argue that you want to do everything with event sourcing / kappa and use Kafka + specialised data stores. GraphQL fits this universe perfectly. It also fits the one where you only use a single SQL DB since a GraphQL query translates quite nicely to SQL with minimal amount of code in between.
- dragonwriter 9y agoUsing SQL as a query language doesn't limit your choice of backend data source(s) any more than using GraphQL does.
- exogen 9y ago
- dmitriid 9y ago> GraphQL knows all of the data requirements for a UI component up front, enabling new types of server functionality. For example, batching and caching underlying API calls within a single query becomes easy with GraphQL. And immediately after that the article spends two pages of text explaining how insanely complex the "becomes easy with GraphQL" really is, and offers no actual details on the "easy" part. Oh, your client has to be cache aware. Oh, and there has to be a gateway that's cache aware, and schema aware, and has to cache all responses... And invalidate them... But there are no tools yet. And then the graphql server should be cache aware. Oh, and your database layer should also cache all responses. Caching is a hard problem, and there's nothing in GraphQL to make it easier. Heck, exclusively relying on POST requests they deliberately remove the most obvious and the easiest part of the equation. I love how the every next part, starts ,with a sentence that shows how complex caching with GraphQL is (emphasis mine): > With GraphQL, frontend developers have the capability to work with data in a much more fine-grained way than with endpoint-based systems. They can ask for exactly what they need, and skip fields they aren’t going to use. I would love to see an explanation how GraphQL makes caching for this easy. > Schema stitching is a simple concept: GraphQL makes it easy to combine multiple APIs into one, so you can implement different parts of your schema as independent services. These services can be deployed separately, written in different languages, or maybe even owned by different organizations. It's called REST APIs and we've known how to do them since 2001.
- Cthulhu_ 9y ago> It's called REST APIs and we've known how to do them since 2001. The aim of GraphQL insofar as I understand it is that instead of having to develop two things (a front-end and a back-end REST API that talks to your database or other services), you need just one (a front-end that talks to GraphQL). Mind you, graphQL becomes the back-end-for-front-end then, and will still need a lot of work. The main point is that with GraphQL you'll only need one for all of your apps, while traditionally you'd write one REST API for each client.
- dmitriid 9y ago> you'd write one REST API for each client. Erm... What? Granted, web requirements are a bit different from mobile requirements, but still. Why would you write one REST API for each client?
- boubiyeah 9y agoGraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see no reason to change as we've never had performance issues. Most companies are not Facebook with 1 billion customers. The fact that clients can compose their own queries brings nothing new, as you still have to allow these capabilities on your server, just like with REST; you have to code against all the possible variations (primary resources, filters, sorts, etc) and optimize the DB/remote reads. So no, the users have no more freedom, the server remains the limiting factor. The way it lets you compose queries is nice for developers, but you can very easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses (which also makes it nice to use with human tools like POSTman) and you can still cache the individual REST responses with Varnish, etc. Doing Subscriptions or mutations over GrapQL brings very little benefits. In fact, it's even dangerous as most system shouldn't allow multiple mutations per request. The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right. The default in Relay used to be "cache forever", this can't be serious. You could only do that if the current user was the only person able to modify the data or if you could guarantee a perfect synchronization with the server via continuous events and that's actually pretty hard to get right and generally a big investment. In practise, most apps/sites don't work like that. I'm not sure what that leaves? "Free" barebone documentation? You can have that too with a good type system (e.g scala's) albeit with a lot more work but with a much nicer type system / expressivity. I mean, I get why it's popular, but the thing's totally blown out of proportion.
- mej10 9y agoDo you have good examples of > easily do that with a single aggregation REST endpoint too, provided you have resource links in your responses I work with/on a "REST" API that has about 20 types of objects, 5-100 fields on each, with many different relationships between them. We've been looking at GraphQL to solve both the querying and mutation aspect, since it is extremely cumbersome to do it efficiently. GraphQL seems great for this case, but if there is some way just adding resource links could get us most of the benefits I'd love to hear it!
- 9y ago
- djmashko2 9y ago(Author of the post here) If you aren't yet familiar with GraphQL and the problems it solves, it might be better to watch the talk on YouTube, since it includes much more of an introduction from the start, plus more color and detail: https://www.youtube.com/watch?v=ykp6Za9rM58 https://www.youtube.com/watch?v=ykp6Za9rM58 The blog post summary glosses over the introduction and focuses on what a GraphQL-familiar audience will find new, so it's all in the context of the current GraphQL community. You can also catch up on some of the tools and benefits, and see some case studies from people using GraphQL in production, on our Explore GraphQL site: https://www.graphql.com/ https://www.graphql.com/
- DigitalJack 9y agoI'm an admitted dumbo about this stuff. Here's what it looked like from that point of view: Hey cool, a new nice looking common query language that can do neat composition of results. Perfect, I've been wanting to break free of the SQL box since forever. Wait, what? You have to write SQL queries for everything still? So you define types, and have to write SQL queries for those types, and graphQL gives you some composition on top of that? Seems kind of redundant. Like wrapping your own christmas present. But then I realize I'm thinking from the perspective of a one/two person team. Perhaps the real value of this comes from very decoupled consumers.
- djmashko2 9y agoYou're in luck, there are libraries that can do it for you! https://github.com/stems/join-monster https://github.com/stems/join-monster And even a system that generates your whole schema: https://github.com/postgraphql/postgraphql https://github.com/postgraphql/postgraphql Plus, the Graphcool framework allows you to bring your own DB: https://github.com/graphcool/framework https://github.com/graphcool/framework
- DigitalJack 9y agoHoly crap, that's awesome, thanks!
- habitue 9y agoYeah the benefits are mainly when you have many different consumers all of whom want to look at the data in different ways, or when you have many different data sources in your architecture and want to aggregate them on the fly based on the exact incoming query. If you're writing rest endpoints for an SPA and you have one backing store, then the benefits are not really there, it's just another layer. There are some nice things in relay like intelligent caching portions of the data and only refetching the parts needed, but it is very likely not worth it if you can just handcraft your endpoints and make your consumer change in sync.
- orclev 9y agoI think what you're missing is that GraphQL isn't SQL, but rather a SQL-ish query language that supports a limited subset of what SQL does. Additionally, GraphQL lets the server define the schema that's being exposed to the client independent of the actual storage underneath that, including defining and limiting the types of mutations that can be applied. If you were to simply expose the ability for clients to feed SQL queries into your backend then you have to worry about policing those queries, scrubbing problematic values out of the queries, and in general preventing users from doing bad things with your database. By exposing a GraphQL interface you're providing a limited and tightly controlled view into your data, but still allowing the client the freedom to specify the shape and partitioning of the data being returned.
- kyberias 9y agoHow is this different, better, worse than OData? http://www.odata.org/ http://www.odata.org/
- voidr 9y agoThe thing that bothers me about GraphQL is that it adds multiple layers that I have to debug if something goes wrong. I have an app that displays a hello world from the server, and it's not displaying, where is the problem? Is it in my UI code? is it in Relay? is it in the server side part of GraphQL? is it in my actual API that returns hello world? If I'm using a good MVC framework on a the backend, I most likely model my schema already in some way, having to duplicate that same information for GraphQL feels wrong. GraphQL fixes the over-fetching problem, however it requires me to implement a server side component for this, that makes me think if it would be less effort to just refine the server side endpoints and not having to support an extra service.
- timsuchanek 9y agoFor anyone interested how a concrete implementation of this architecture can look like, we created an example project that includes the Gateway pattern with schema stitching and powerful resolver middlewares: https://github.com/graphcool/graphql-boilerplate https://github.com/graphcool/graphql-boilerplate
- sean_lynch 9y agoI'm interested in GraphQL but definitely haven't been following closely. This seems to be a marketing video for Apollo's products. Is that what most GraphQL stacks look like in production these days?