4 ms·

I am with you. Every time I looked at GraphQL or asked to implement one, I had to say no. How is this a good thing for the backend or infra engineers? It's a m

• sailfast 4y ago
  It’s not, really, but it IS a good thing for feature development speed if that’s what you’re into, and might help a team figure out quickly which data is critical to optimize for once you start putting more serious data loads through your APIs?
• brentm 4y ago
  100% - I can see how it might be great for FB where they have the capacity to optimize but without that engineering capacity it seems like it would turn into a net negative.
• ehutch79 4y ago
  No one sees the backend. So who cares? /s With ORMs at least, the developer is likely either thinking about limitations, or really needs the guide-rails an ORM provides. I doubt a lot of front end engineers, many of which probably have never optimized a DB, are thinking about the consequences of their queries.
  • dustymcp 4y ago
    I can say for sure this is the case
  • freedomben 4y ago
    what you say is unpopular, but it's a lot more true than most people (especially front end people in this case) want to admit. Of course there are plenty of exceptions (people on FE who think about, care about, and know about what happens on the backend), particularly the Venn diagram of FE people reading HN, but the majority in the industry definitely do not. The bigger and/or more specialized the company, the worse that problem gets. To be clear, this is not just a problem for FE people. extremely normal for humans to become myopic in the areas they spend the most time in. FE does it, BE does it, management does it, everyone does it. Find a standard mobile engineer doing native iOS or Android, and they're going to be even more disconnected from the effects on the backend, and they come by it honestly. If you tend to specialize more in one area, building an awareness of your own biases/perspective, and exercising intentional empathy, can make a huge difference in how easy you are to work with. When looking at dysfunctional engineering orgs, one of the first things I do is figure out where the "power" is and figure out their backgrounds. The most extreme example might be a company founded by a FE eng for whom backend is just a necessarily evil to support their app. Or a company founded by a BE guy for whom the real value is the API, and the clients are just there to abstract it for normal people. Taking this in and finding a healthy balance of the way things are structured can help improve a dysfunctional org a lot. FE, BE, DevOps/Infra, etc are important pieces in an overall puzzle. Without a well-functioning team behind each, the company and product suffer.
  • blakesley 4y ago
    I'm still pretty new to dev, but what's wrong with ORMs? And, importantly, what would you recommend instead?
    • anthonypasq 4y ago
      ORM's are fine for the majority of simple use cases. When things get complicated you end up either fighting with the ORM or just overriding it and writing the sql yourself anyway.
      • ehutch79 4y ago
        Yes, there definitely need to be escape hatches for situations where you need to write sql. But that should be rare. If you're commonly bailing to raw sql, I'd say there's something wrong, probably a poor fit of the orm to the problem.
        • ryanbrunner 4y ago
          I'll use raw SQL (maybe not as an entire query, but something like a computed column) pretty often, for situations where I want to query things like "give me all foos with a count of bars related to them", or "give me a list of foos with the name of the latest related baz". Most ORMs would want to hydrate the graph of related objects to do that, or at least have multiple round trips to the DB server.
          • ehutch79 4y ago
            That doesn't sound like a good ORM. They should be lazy until you access the relevant data. That said. This is where the knowing what's going on behind the scenes matters.
            • ryanbrunner 4y ago
              Oh they would be lazy, it's just that expressing something like that efficiently (i.e. something like "SELECT foo.*, (SELECT count(1) FROM bar where foo_id = foo.id") is usually really hard to do. Most ORMs I've seen would N+1 on that with a naive approach, and even the "optimized" approach will want to fetch all bars vs. just the counts.
  • ryanbrunner 4y ago
    ORMs are also pretty easy to use on a case-by-case basis if needed, either by using the escape hatches the ORM provides or by bypassing it altogether. Deciding "oh GraphQL isn't good for this particular use case so I'll spin up a parallel REST API" is a much bigger decision to make.
• ishjoh 4y ago
  Infrastructure is one thing that seems to catch a lot of people off guard. So many infrastructure tools are based on monitoring HTTP codes, but even when there are errors graphql servers send 200s unless modified. It turned into quite the headache for us.
• jopsen 4y ago
  Also REST APIs work nicely with caching proxies and such..