7 ms·
GraphQL Conf. 2021
- dm33tri 5y agoThis website is so laggy, really tells us about the state of frontend in 2021
- hleszek 5y agoGreat! But I don't see any mention of the time and timezone ? EDIT: if you subscribe, you can add the event to your google calendar and it shows: 17:00 - 21:50 (UTC+2)
- wongarsu 5y agoThat will probably become obvious once they publish the schedule, but right now I can't find it either.
- adeptima 5y agoWishlist for presenters to address the following - GraphQL performance issues - GraphQL makes tasks more complex - GraphQL schemas confuse junior devs, higher entry level - REST cache easier - REST if you understand what you are doing ... can do the same - REST is better for error handling and tooling
- pikachuproblem 5y agoCFPs are open if you want to talk about this too, solid topic
- robjan 5y agoA lot of these can be addressed using a combination of Apollo GraphQL and dataloaders. This is especially true if you move most of the hard work to the backend and use optimistic updating on the front-end to improve the user experience.
- adeptima 5y ago- GraphQL leads to a vendor lock commitment ... which is great if you can sell it to your clients and dominate with your expertise https://www.apollographql.com/docs/apollo-server/data/data-sources/ https://www.apollographql.com/docs/apollo-server/data/data-s...
- robjan 5y agoGraphQL is an open standard. If you don't like Apollo which, by the way, is open source; you can choose other libraries. To an extent all technology choices produce some level of lock-in, including REST, otherwise you end up rolling your own operating system and transport layer.
- hn_throwaway_99 5y agoThis is plain absurd, especially given the page you linked to is about completely free and open source tools.
- adeptima 5y agoDont think it's absurd... This is just an objection in sales terms. First impression is very hard to change. This is why I asked I wish someone address it more.
- hn_throwaway_99 5y agoI just am baffled how someone can think there is a lot of "vendor lock in" with GraphQL. I am a huge fan of GraphQL, I have used it on large, production systems for years, and I have never even paid any money to any GraphQL tool vendors. Basically all of the good tools are completely free and open source.
- dtech 5y agoI basically disagree with all of these. Graphql isn't that complex, not more complex than the widely accepted SQL schema + query. Tooling is top-notch (Graphql-codegen, Apollo, Postman, Graphql playground), and is quite easy to use. Junior devs become up-to-speed with GraphQL a lot faster in my experience, because there is a lot more homogeneity in GraphQL while everyone implements their own flavor of REST
- jayd16 5y agoYou're often dealing with multiple data sources, no transaction syntax and weaker tools for EXPLAIN and optimizations. Seems way more complex than SQL.
- adeptima 5y ago- GraphQL = Apollo GraphQL ... Apollo community people are evangelizing it really hard?
- deleted 5y ago[deleted]
- fnord77 5y agoyou say "evangelists" I say "shills"
- DenisIzmaylov 5y agoYeah, right! 100% agree especially with vendor locking. And security. And there is a few things to talk about gRPC vs GraphQL, gRPC and REST API.
- the_arun 5y agoGraphQL on top of gRPC makes more sense than GraphQL on top of REST.
- dmalik 5y agoAs a front end developer my life is much less complex with GraphQL, especially with TypeScript in React. I'm curious, what tasks do you find more complex?
- adeptima 5y agoAdvanced "Left Join" query building similar to Crunchbase search https://www.crunchbase.com/search/ https://www.crunchbase.com/search/ ... with lot of deep LEFT JOIN behind. Opted out for Golang with REST after prototyping with GraphQL
- cpursley 5y agoI'm able to do super complex joins with Postgres views and Hasura or Absinthe (Elixir Phoenix). YMMV.
- sillyquiet 5y agoThis is my experience too. A negotiated schema + Typescript means many fewer bugs due to unexpected data shapes. Also error conditions are much more understandable. Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency.
- dragonwriter 5y ago> Also, GraphQL is not a replacement for REST... I am not sure why people keep making this equivalency. GraphQL is arguably consistent with actual REST, but its a replacement for trivial JSON CRUD over HTTP, which is one of the common abuses of the term “REST”.
- collyw 5y agoI thought everything went over a Post requests and returned 200 error codes whatever. Doesn't sound like REST to me.
- 5y ago
- nivertech 5y ago- GraphQL makes tasks more complex because GraphQL APIs generally have much higher quality than REST-like HTTP APIs. Designing a proper RESTful HTTP API is actually much harder than the GraphQL one. - GraphQL schemas confuse junior devs, higher entry level Junior devs will learn whatever is used in the company. IMO the problem is with inertia by devs who are only experienced with REST-like HTTP APIs - REST if you understand what you are doing ... can do the same if you understand what you are doing ... you can do anything - REST is better for error handling and tooling I disagree: GraphQL has good tooling, and better error handling patterns. But yes it requires some upfront design.
- bpicolo 5y agoI've found the opposite. Designing a GraphQL API with the extended tail of important features has been an awful lot harder than with REST Apis. That's not just in terms of idioms (which are useful for abstraction layer sake), but authorization, performance, all the sorts of things that are very known quantities, with extensive framework integration, in REST land. You get a lot farther with the wide ecosystem of tracing and monitoring tools, API gateways, authenticating proxies, all these API integration points and what have you in JSON api land. In specific language ecosystems with a specific choice of tooling and libraries you can ultimately make good things happen, but it's not nearly as universal. Apollo is an obvious contender. I also like HotChocolate in the dotnet ecosystem. There are definitely benefits. GraphQL having typed schematization by default is huge, and arguably that's the best feature. That's something you need to be more disciplined about in REST land (e.g. OpenAPI). But there's good tooling to be had on those fronts as well. Arbitrarily-shaped types definitely come with their own set of maintenance challenges versus more static DTOs. P.S. HotChocolate's EFCore integration [0] is some of the coolest library tech I've seen. Thanks to C#'s builtin data projection functionality (via LINQ), it's able to automatically build a Hasura-style fully baked GraphQL API directly from your database domain model (which you can transform arbitrarily to limit / add additional functionality to via LINQ). It's still not my default choice in a new app, but if I were going to invest in GraphQL it's probably the strongest contender [0]: https://chillicream.com/blog/2020/03/18/entity-framework https://chillicream.com/blog/2020/03/18/entity-framework
- fnord77 5y agographql seems like the SOAP craze - a concept with horrific complexity and lack of scalability, being marketed hard by firms that profit from complex solutions.
- deleted 5y ago[deleted]
- the_arun 5y agoGraphQL makes sense for building user experience. Not so much for server side. gRPC is way better for server-server
- deleted 5y ago[deleted]
- slver 5y agoThere’s almost no overlap between SOAP and GraphQL (еxcept that you seem to not be familiar with either of them). Especially odd is the "scalability" remark, given those are protocols, they have no bearing on any aspect of the "scalability" of the implementation that I can think of. Actually both SOAP and GraphQL are often used as aggregate endpoints for exposing internal APIs, often for the infrastructure of entire companies (see how GraphQL is used at Netflix for example). So they're predominantly used where you NEED scale, and REST fails them, due to the heterogenous nature of their clients (external and internal) vs. the "prebaked" structure of REST as a large-grain resource protocol (Fielding's words, not mine). And the "companies that profit from complex solutions" is a rather poor theory. GraphQL was designed by Facebook, which doesn't profit from "complex solutions". Quite the opposite, they want APIs that are accessible both to their teams and the world. Same with Netflix. GitHub. Shopify. Airbnb. PayPal. Where are those evil companies conspiring to profit from complexity?
- fnord77 5y ago> There’s almost no overlap between SOAP and GraphQL oh they're entirely similar - overly complex data transfer schemes. They both also push too much responsibility on to the client. They also have steep learning curves. It may have started at facebook, but the graphql industry has a life of its own now. I've seen this with many technologies. People start tooling and consulting companies around some technology and start pushing it hard. If it isn't needlessly complex, why does it have its own conference? https://goodapi.co/blog/rest-vs-graphql https://goodapi.co/blog/rest-vs-graphql https://news.ycombinator.com/item?id=17565508 https://news.ycombinator.com/item?id=17565508 https://blog.hitchhq.com/graphql-3-reasons-not-to-use-it-7715f60cb934 https://blog.hitchhq.com/graphql-3-reasons-not-to-use-it-771... https://www.reddit.com/r/javascript/comments/ifxvo0/why_i_dont_use_graphql_anymore/g2qo5s1/ https://www.reddit.com/r/javascript/comments/ifxvo0/why_i_do...
- jrsj 5y agoNotice nobody actually tackling the “performance issues” part of this, because that is the real problem most experience. A standard implementation gives you n+1 in many scenarios (assuming you don’t have GraphQL on top of a single SQL database or something along those lines). So how do you fix that? Well you’ve got to do query introspection to resolve certain queries in a more optimized way. Which tends to be more complicated than just…doing exactly what you want to do via a REST endpoint. Now I’m not saying this isn’t worth it. In many cases it probably is assuming the people implementing your GraphQL server are competent engineers that will be able to optimize where it matters and make it scale. IMO it’s just worth recognizing that it does take more skill to implement a GraphQL server well.
- quonn 5y agoGraphQL solves a frontend problem and also makes it possible to address the n+1 problem. REST only makes it possible if you add batch/specialized endpoints which is not very RESTful and is exactly the same optimization than for GraphQL. Whether the introspection is hard or not depends on the library. A good library provides you with a set of queries sub-paths and then it‘s trivial to pre-fetch those at an outer resolver.
- collyw 5y agoWhere does the idea that "nested objects in responses are not RESTful" come from? It seems very common from graphql enthusiasts.
- quonn 5y agoNested objects are fine, making a custom endpoint to provide what the client just needs is not what you will find in real REST APIs in the real world. So a lot of n+1 type of requests are made and much of the data is discarded. I wonder why this is even controversial now. APIs have been like that for about 15 years and GraphQL was created to address that and it does it very, very well. edit: slver has explained my point of view much better than I have here.
- quonn 5y agoA Turing tarpit can do the same, too. Where are your arguments? There are exactly zero and now everyone in the thread has to work to debunk these baseless claims. There are exactly two almost valid points in here: The default implementation has some overhead (for query validation). That may cause performance issues. If you deliver public data where the full response can be cached, then REST makes that slightly easier (GraphQL discourages transport by HTTP GET). I have worked with both for many years, GraphQL solves many real world problems. However you might only understand that as a full stack or frontend developer. If you only write APIs on the backend it appears pointless of course.
- jlouis 5y agoIt can be argued you can remove query validation from the critical path entirely. Though in my experience, it's a very small fraction of the actual processing time by Amdahl.
- quonn 5y agoCorrect, it can be removed. It depends on what you do. I worked on an application that could be cached heavily and got a very large number of requests and as a result the query parsing and validation mattered.
- collyw 5y agoCurious about making tasks more complex. A new dev at my work is pushing for graphql, and I am sceptical. We have way to much complexity at present and it seems like a new less understood tech that is only going to increase complexity rather than reduce it. Do you have any examples you are willing to share.
- slver 5y agoGraphQL is a fine-grained resource protocol, and REST is a large-grained resource protocol. You don't want to serve thousands of 50 byte responses in REST just to get what you need when your app opens, this is why GraphQL allows you to specify this in one response by selecting what you want in the query. Can you implement this over REST? You can pretend you can, but if you put all those parameters in the URL and have countless ways of fetching the same data via infinite resource URLs, you're essentially bastardizing the concept of one URL one resource, or the idea that your entities each has its own URL, rather than inlining them in countless ways through one-off aggregate resources. TLDR; REST really doesn't do what GraphQL does. And when you try to make REST do what GraphQL does, it ceases to be REST.
- SkyPuncher 5y agoPerformance issues are not unique to GraphQL. There's a fundamental data modelling issue that any relational-based system needs to address somewhere in the stack. Data is stored in more than one table and that data often needs to be joined together for the frontend. Embedded REST apis have the same fundamental issue. That work is just "hidden" inside some sort of server side function. ---- Imo, GraphQL and REST face the same fundamental performance issues. The difference is GraphQL allows clients to optimize the data they need in the response. I'd you have a GraphQL performance issue, you'll likely have a similar or worse REST issue.
- itsbits 5y agoHas GraphQL cracked role based data fetching patterns? I would love to learn those patterns..
- steve76 5y agoI use next-auth, relay-nextjs, and jwt on PostGraphile: https://www.graphile.org/postgraphile/jwt-guide/ https://www.graphile.org/postgraphile/jwt-guide/
- jrsj 5y agoAs someone who works on multi tenant systems where accidentally crossing boundaries would result in millions of dollars in fines…yeah I would like to see more examples of this in particular haha
- aniforprez 5y agoWhat about caching? I'm not sure I like my frontend libraries trying to solve caching when I could very easily get that incredibly simply for free with REST and browser or endpoint caching. I'm really hard pressed to find proper examples that describe auth, RBAC, UBAC, caching etc with GraphQL When it first came about it seemed like a band-aid to try and get around poorly designed REST systems so backend engineers wouldn't have to deal with frontend devs asking for data and new endpoints. I dunno if it's matured enough past that. Not saying REST is perfect and lord knows enough companies abuse it but a lot of stuff is pretty solved with simple, well documented solutions online