13 ms·

For me GraphQL is the epitome (in the Web tier) of 'we need to solve the same problems as FAANG does'. You'll likely never be in a situation where over-queryin

• kochthesecond 6y ago
  I dont disagree with this, but I also see in our case that good tooling is immensely valuable in keeping things consistent and moving forward (in the same direction) without having to discuss every change.
• jmnicolas 6y ago
  > You'll likely never be in a situation where over-querying via a non-granular REST call will ever be an issue worth optimising around. While I agree with your beginning sentence, the one I quoted doesn't sit well with me. It would be good to remember that not everybody has 100 Mbits fiber or 5G download speed. We all saw the data on how milliseconds affect user retention then proceed to completely forget about it once building our apps. I think we can do better.
  • HeyHoJoe 6y ago
    Even if users don’t have 5G, why is your rest api so slow that it’s an issue? Why is graphql the solution? The featured article points out that optimising rest can be a better solution, in terms of time and effort, than implementing graphql. The problem that graphql solves isn’t this one.
  • jamil7 6y ago
    Agreed but I think the point was over fetching is likely very far down the list of optimisations.
• ryanar 6y ago
  GraphQL also allows the frontend team to iterate faster, because they don't need to ask the API team to change an endpoint, or add one. The API team also moves faster, they define the relationships and they are done, no going back and updating endpoints. GraphQL creates a data graph that powers the UI, REST creates a database that you can query on the UI and you have to compose it all together and manage.
  • HeyHoJoe 6y ago
    What if you don’t have separate teams, or what if your teams are in the same room? Why do you want your frontend to select it’s own data rather than consuming predefined known quantities? Is this not analogous to type safety? Is graphql not in fact closer to having a database that you query from the frontend, not least of all because it literally has ‘query language’ in the name?
    • andrewingram 6y ago
      At my last place the "product" team owned the clients (website, app) and the GraphQL layer, and the "platform" team owned the business logic just beneath the GraphQL layer (it happened to be in monolith though, so the boundaries between teams were intentionally fuzzy).
    • balfirevic 6y ago
      > What if you don’t have separate teams, or what if your teams are in the same room? Why do you want your frontend to select it’s own data rather than consuming predefined known quantities? Then you don't share many of the reasons GraphQL was originally created for. Act accordingly.
    • astatine 6y ago
      I agree. Sometimes it seems like GraphQL degenerates into a generic REST API where you construct and pass the SQL directly from the client.
      • cratermoon 6y ago
• dmitriid 6y ago
  One good fit we may have found is for back office/admin. In a company you often have APIs geared for client apps, and then internal APIs between services. But rarely anyone develops good APIs for backoffice. And then you have an admin interface struggling to retrieve the data it needs from a dozen different API calls. Slap a simple GraphQL server in front of these dozen calls, and you have a more streamlined development for internal tools.
  • rrook 6y ago
    Sounds like you agree with the OP; " But rarely anyone develops good APIs for backoffice" describes an organizational problem, and the way you've described using GQL does indeed sound like it's bandaiding that problem.
    • dmitriid 6y ago
      Indeed, this is more of an organisational problem and the question of what to prioritise next. Backoffice is usually de-prioritised in favor of customer-facing features.
• dudul 6y ago
  You say band aid, I say that it can be a great catalyst to "leave past, bad practices behind". Don't discount the psychological effect of switching to a new paradigm. It can truly empower people to feel that they can "do it right". I'm not saying it's enough, far from it. Bit it can be a very liberating 1st step.
• HeyHoJoe 6y ago
  I completely agree. Too often developers fall into the trap of engineering solutions inappropriate to the size and scale of their business.
  • jensneuse 6y ago
    This 1000x
• jensneuse 6y ago
  You're making a very good point here. You should always ask yourself if it's really worth it.
• danjac 6y ago
  So a bit like microservices?
• sho 6y ago
  As something of a war-weary veteran - I disagree. It's a good instinct to be suspicious of new technology. But I have personally seen, many times, what REST APIs can grow into - unless you are very, very careful, "get user/1" can turn into god objects with every field under the sun, non-optional. I've seen `users/l` be over a megabyte with (eg) comments, friends, comments of friends, likes, likes of friends, and every other thing the front end team ever asked for. GraphQL solves that. Yes, it can be avoided with strict, diligent design. But it often isn't. GraphQL solves the whole class of problem. And that's why I like it, despite my mistrust of "new hotness" technology.
  • HeyHoJoe 6y ago
    I think that’s just pretty basic bad design, to be honest.
    • diveanon 6y ago
      Thats the whole point, REST facilitates and often encourages bad design.
      • berkes 6y ago
        How does it encourage this, and how does graphQL discourage this? I've always held a strict rule where The R in REST stands for Resource (which isn't true). There's a user, an Invitation (and not an invite action on user, nor a state:invited or invited_at on user). there's a Session. There's links that clients follow, and everything is as small as possible. I really don't see how REST encourages God objects.
        • diveanon 6y ago
          I have seen many people try to solve the "too many requests" problem by slowing expanding rest responses into "god" objects. GQL solves this problem elegantly by allowing you to specify the data that you need in a single request. That is just one example, there are many many others that you can google if you are actually interested.
• diveanon 6y ago
  Some people do need to solve the same problems as FAANG, and GQL is a excellent solution to those problems. Some people also want an agile api surface so they can iterate quickly, GQL is an excellent solution to that problem. It is also an excellent solution for: - client side caching - unified RBAC - service stitching / microservice hell - api documentation via graphiql - decoupling FE dev from api dev - api automation - typed api surface The list goes on. To say that GQL is a just a band aid for bad leadership is nonsense, and discounts the very real reasons that many many experienced teams are switching to it. I would encourage you to re-evaluate your position as if you voiced those opinions in an interview with basically anyone I know you would quickly get passed up in favor someone that actually knows what they are talking about.
  • HeyHoJoe 6y ago
    > I would encourage you to re-evaluate your position as if you voiced those opinions in an interview with basically anyone I know you would quickly get passed up in favor someone that actually knows what they are talking about. Ha. Now we’re introducing threats. Don’t agree with my technical opinions? You’ll never work in this town again! Funny, funny stuff.
    • joelbluminator 6y ago
      Unfortunately he's somewhat right. Not because the interviewers necessarily know wtf they're talking - they probably don't. But going against the current hype in an interview can only hurt your chances. Liking something like GraphQL, or React, or Framework Of The Month can't really hurt you even if your interviewer doesn't like it. But not liking it can be a real issue! I would suggest at least staying neutral on the current hype stacks in an interview. It's like debating religion - don't go there...
      • diveanon 6y ago
        So not liking the tools your employer uses makes you less appealing as a candidate? Also, React is a hype stack now?
• ecf 6y ago
  GQL has issues like every tech does, but it feels so much more ergonomic from an api consumer point of view. Simply point Insomnia at the base url and it’ll introspect the schema and provide typed query auto completion. No dozens of requests to different endpoints with different query parameters than can only be kept track of by having the api docs open on a second screen.
  • deckard1 6y ago
    It's only ergonomic if you've never done REST before. I'm not being flippant. If you're already using REST tools such as Postman and every caching tool in existence (browser, http proxy, etc. etc.) then GraphQL tossing it all out is the exact opposite of "ergonomic." The caching story in GraphQL is a joke. What the browser gives you for free with GET caching takes weeks and months of fine-tuning and tweaking and head scratching with something like Apollo. Then you'll probably try decreasing the payload size (there's a third-party solution for this), or batching requests together (guess what... there is a third-party solution for this too). The amount of tooling and implementation work GraphQL needs to get up to par with built-in REST is pretty incredible.
• SkyPuncher 6y ago
  > For me GraphQL is the epitome (in the Web tier) of 'we need to solve the same problems as FAANG does'. I work at a small startup. We use a REST and Redux architecture. It's worked very well for us, but we're starting to hit some pain points. As we look to re-architect, our list of challenges pretty much mimic the challenges GraphQL looks to address. These aren't scaling issues or "big company issues". In my opinion, they're core issues with every client-server code base. * Client Data and Statement Management * API Coordination and Versioning (even more complex if you have a public API) * Payload Management and Relational Data (it can be very expensive to pro-actively return embedded/dependent data, so you need to manage it somehow) * Caching and De-deduping * Typing and Data Interfaces between Client/Server * Error Management (not that hard to standardize, but still something you need to account for) * Pagination, Filtering, Sorting, etc.
  • jrsj 6y ago
    There are issues that you get with GraphQL that are generally much easier to solve with REST, though. While it's easy to set up a GraphQL API that technically makes your whole graph available, going off of your default resolver functions alone is going to cause serious performance issues as soon as queries start to get more complex. The default behavior is basically n+1. To fix that, you have to do query introspection, which is significantly more complicated than just having a dedicated endpoint. Depending on your data sources & how easy it is to cache, this can be more or less of a problem. This isn't to say that GraphQL is bad or anything, but there are definitely some gotchas that are important to evaluate before diving in.
    • csnweb 6y ago
      The n+1 problem can be fixed without introspection by using dataloaders: https://github.com/graphql/dataloader https://github.com/graphql/dataloader. It's actually quite pleasant to work with them, but it's definitely one more thing you need to know.
  • Quekid5 6y ago
    (I'm arguing theoretically here:) > I work at a small startup. This means you can afford a lot of technical debt, even such technical debt as might be incurred by GraphQL (as argued by the post and many people in this conversation). The concerns you've posted are certainly valid, but GraphQL is not the only (or even necessarily best) way to address them. If you have a huge engineering staff like FB, then perhaps it's better to just "move the complexity to server side", but for most businesses that not what's going to happen. What's going to happen in practice is DoS galore.
• csomar 6y ago
  > You'll likely never be in a situation where over-querying via a non-granular REST call will ever be an issue worth optimising around. Sure, but that's only one advantage of GraphQl. Personally, I'd use GraphQl even for the smallest of apps. With statically generated sites, you can forgo a back-end server and just setup a GraphQl instance. It's a one-time cost to learn, and then you easily setup your APIs and if you are using React/Vuejs, it's even easier to integrate with your API.
• junon 6y ago
  Well said. Plus, the fact that proper query-based load balancing now has to read, parse and interpret (based on the currently deployed application) the entire HTTP request in order to make any balancing decisions, whereas header-based (see: path-based) balancing only had to read a small portion of the request before forwarding all remaining connection traffic to the destination backend service after request replaying. GraphQL has never made sense to me for anything beyond toy or small-scale projects.
• TameAntelope 6y ago
  I would strongly disagree. Scale is scale, and though I don't have the volume problems that FAANG have, I also have substantially fewer resources. Being able to very quickly connect a series of tools and tech together in a way that is selective of the data being moved around saves me money and time, period. That matters.
• afarrell 6y ago
  > it's a band-aid around dysfunctional inter-team working. If inter-team communication isn't a hard problem in software development, why are we even talking about API technologies? If inter-team communication wasn't that hard, you could just email pc and ask him to email you a snippet of Ruby to process a credit card payment.
• say_it_as_it_is 6y ago
  You posted this comment 10 hours ago and it's at the top, despite the down votes and biased opinions by people who have a lot to lose if you're right. The silent majority seems to agree with you.
  • mattbillenstein 6y ago
    Eh, I think it's "get off my lawn" folks supporting this -- I'd like to see a tally of folks who've actually built GraphQL apis. I do agree a lot of software is built just for the sake of software - there is loads of needless complexity in things. But GraphQL is not that imho.
• thayne 6y ago
  Working for a company much smaller than FAANG, I've seen issues with REST. However, the waterfall problem was a small issue compared with problems with bandwidth and server-side compute when you are processing and returning more data than is actually needed. That isn't to say that graphql is a magic bullet for those problems, but the issues with REST can show up far before you get to FAANG scale.
• Diesel555 6y ago
  I'm surprised at all the people that prefer REST over GraphQL. I'm a developer of my own projects for fun. I don't work in tech. My frontends are on iOS / Android / the web with Typescript. So my confusion is from a perspective without expertise. I started with REST via Django and a few others, and now I've switched to GraphQL. I love GraphQL over REST backends due to the type automation tools such as GraphQL Code Generator and query tools like Apollo. Also being able to construct a query and access children via one request is super nice. For example my old REST APIs call for a post, then get pictures for that post, then get comments for that post, then gets the username and other user data for the owner that made the comment. It's four requests. My GraphQL requests just get them all in one customizable request. Post can contain pictures and comments and all their properties. Comments can contain the owner of the comment and all its properties to include things like username. The result is a typescript object that is strongly typed and has all the data I need. Before GraphQL, in REST, this would be four requests, three of which are in series (post -> comment -> owner to get username). I know I could make a custom REST API to do the same thing, but it was just so easy in GraphQL, I didn't have to worry about it. I'm not working in teams, I'm not creating a super large backend, it's not complex projects... so I don't know what I don't know. But what am I missing? Maybe not everyone needs / uses the typing I do? That's the big benefit for me. Maybe not everyone cares about being able to query children (or create children via a nested create)? Maybe these things were easier than how I was doing it in REST?
  • pault 6y ago
    These are all excellent points in favor of productivity with GraphQL. I always avoid new technologies for a few years to let the hype cycle mature (for example, everybody talking about how great mongodb is and writing blog posts about how they migrated, followed two years later by everybody talking about how terrible mongodb is and how they had to migrate to posgresql). As a dev working on a commercial software project, especially if you're in leadership, you have to look very carefully at every technology you introduce into your stack, because you are going to be supporting it for years. If it turns out to be the wrong decision, or you get caught out by a bunch of edge cases that weren't well known in the early days, you can end up losing millions of dollars in productivity, and possibly killing the company when you can't fix bugs and ship new features. So I've been suspicious of GraphQL, but keeping an eye on it. I still don't know if the productivity gains you get up front are actually technical debt in disguise, but if that turns out not to be the case, and it really is a matter of only having to write one query instead of making five requests and several dozen lines of types, validators, and async redux middleware, I'll be happy to adopt it in the future.
• underwater 6y ago
  > If you're shipping multi-megs of JS to a client don't then pretend that micro-optimisating the API call waterfall is your KPI, it's just disingenuous at best. It absolutely is the bottleneck in almost every web app that relies on Ajax fetches. The latency is an absolute killer. On every app that I've optimised, I have to get people to stop going with their gut and look at the traces (both synthetic and real-user). People generally think they should be optimising their JS execution. But in fact the most important thing is usually sequencing loading correctly, followed by minimising JS bundle sizes. Modern browsers are getting really good at parallelising loading and parsing JS and other resources. But if you're whacking some fetch in there that happens as a result of JS execution then you're generally looking at a wasted 300-500ms for most endpoints/device combos.
• mattbillenstein 6y ago
  Disagree - GraphQL is a legit better way to build APIs. As a backend engineer, I publish a schema of all the available data - the frontend can fetch it in any shape it prefers. Web UIs and mobile UIs often have different views, so they want different data, and fetching it in one request or many is up to the preference of the UI. I don't have to build different REST endpoints presenting some data in a different shape for performance reasons or because different applications wanted to request the data in a different way. As a frontend engineer, all the data is often already there unless I'm building some new feature the backend doesn't understand yet. I'm free to refactor my application without bothering changing the REST API - and GraphIQL lets me inspect the api and mock queries for how I might fetch the data for a given view. It's a cleaner contract to let different people get their job done with less fuss - game changer.
• projectileboy 6y ago
  I respectfully disagree, at least in some contexts. If you support an API that has multiple clients with ever-changing needs, GraphQL can make your life much simpler, with much less code. I can only speak to the experience of using Lacinia in Clojure, but I found it to be fairly easy to use.
• fouc 6y ago
  I thought micro-services is the epitome of 'we need to solve the same problems as FAANG does'
• dosethree 6y ago
  "You'll likely never be in a situation where over-querying via a non-granular REST call will ever be an issue worth optimising around." I've def been in this situation before. But I agree that it it is not the norm