5 ms·

The title is misleading. The post doesn't discover any dark sides of GraphQL. The post is about a potential performance problem with a library that implements t

The title is misleading. The post doesn't discover any dark sides of GraphQL. The post is about a potential performance problem with a library that implements the GraphQL spec. There might be a problem with the library itself. There might be a problem with the use of said library. The author states that it takes 19ms to fetch 20 recipes from a postgres database. This looks really suspicious. Why does it take so long to fetch 20 indexed rows? Maybe there's some general performance problem with the application?

deleted 7y ago
[deleted]
ctvo 7y ago
You focus on and make assumptions it's indexed rows and that ~20ms average for a database call is "suspicious" but you're not concerned about the 400ms flamechart for graphql-js doing validation shown in the thread? graphql-js is the reference implementation of GraphQL, so it's not any random library.
- jensneuse 7y ago
  The graphql-js library focuses on correctness, not on performance. Facebook doesn't invoke it at runtime, only at built time. They use persistent queries only. If you want a high performance server runtime I wouldn't use Node.JS. Especially for a complicated task like validating and resolving a GraphQL query Node.JS is the wrong tool. It's too high level to tweak hot paths and optimize the garbage collector. So no, I don't think the flame graph is suspicious. In my language of choice (go) I could drill down memory and CPU consumption for each line of code to find the bottleneck. Maybe this is possible for Node.JS too, I don't know the tooling so well. I would suggest that if such tool exists a detailed flame graph of the Node.JS application might help understand the issue.
  - swyx 7y ago
    iirc fb doesnt even use graphql-js much? the whole thing was embedded in PHP Ents . graphql-js was written purely for the opensourcing. ofc things may have changed somewhat in recent years but i doubt if
    - lowdose 7y ago
      No I heard they still chew a lot of bubblegum over there.
    - eshyong 7y ago
      Is PHP Ents a type of webserver FB uses?
      - sophiebits 7y ago
        Ent is a (proprietary) database wrapper library resembling an ORM,* but I don’t believe Facebook’s GraphQL server infrastructure is tied to Ent at all. * Though Ent’s creators emphatically claim it is not an ORM, that phrase does give you a rough but directionally-accurate idea of what it is.
        swyx 7y ago
        ah ok. sorry for potential misinformation, i glean only what i can from being a casual outside observer.
  - hn_throwaway_99 7y ago
    OP is using Apollo Server, which is by far the most common server implementation for GraphQL. It may well be there are issues specific to Apollo, but it's definitely worth getting to the bottom of based on how widely used Apollo is. There is nothing in the posts that identifies NodeJS as the culprit, and based on the info I'd be very surprised if it was. It seems most likely that the type validation is what is taking so much time. But then again, strong types are one of the main benefits of GraphQL. If anything, I've found Node to be one of the easiest and most "natural" server languages for GraphQL, and I have implemented GraphQL servers in Node, Java and Python.
    - deleted 7y ago
      [deleted]
    - dnautics 7y ago
      Have you tried elixir's absinthe?
      - deathtrader666 7y ago
        I'm curious to find any performance comparisons between Elixir's Absinthe and Hasura, on a Phoenix app.
        dnautics 7y ago
        I would be extremely (but prepared to be) surprised if Phoenix + Hasura were faster in terms of latency than Phoenix + Absinthe, since one has to enter and exit two vms and the other doesn't, unless you're suggesting the frontend issue graphql results directly to the hasura backend, bypassing phoenix.
        deathtrader666 7y ago
        Two ways one could test - 1] REST client <-> Hasura <-> Phoenix 2] Phoenix-generated HTML <-> Hasura <-> Phoenix
    - 7y ago
  - foota 7y ago
    This comment neglects the fact that people can and do use node in situations where performance is important, and 400ms is especially egregious. Having the obvious path for using graphql in js server side perform terrible is problematic.
    - andrewingram 7y ago
      For a point of comparison, when I was using graphql-js around 3 years ago, I was benchmarking things pretty carefully and the main bottleneck wasn't graphql-js -- I had comparable (or faster) response times to equivalent existing hand-crafted JSON endpoints. But if you're fetching a lot more data than you need for a typical UI, you might run into bottlenecks.
      - foota 7y ago
        Yeah, it sounds like the poster is having issues with their deep hierarchy causing lots of unnecessary object creation? I'm still surprised it had that much overhead though, as I generally think of node as being relatively competitive with Java outside of heavy computation.
        83hajfjeijg 7y ago
        A deep hierarchy? 3 levels? Really? Lots of unnecessary object creation? We're talking about a total of 1600 fields. If that's considered a lot then GraphQL is in worse shape than I thought.
        andrewingram 7y ago
        Deep queries aren't usually a problem as it's usually just waiting on I/O, it's wide queries that are a bigger concern. I just remember that CPU load was very low compared to other metrics, so I mostly focused on fixing memory (which was related to the file descriptor issue) usage. One issue I see a lot of (which happens to be part of the problem in this case) is people overfetching data on their list UI (e.g. search results) so that the detail page data is already in the client side store. But this is usually a premature optimisation and ends up causing more problems than it solves.
  - sciolistse 7y ago
    Regarding profiling in Node.JS (in case anyone who is interested is unaware,) if you start your application with the "--inspect" argument and then open devtools in chrome/chromium there's a little node icon that shows up in the top left corner. If you click on that you can get performance flame graphs / tables, memory profiling, and there's also a REPL for the process, as well as a list of loaded source files so you can set breakpoints through there if you like, as well as modify the files on the fly if you need something more for debugging. It can be very useful, and works pretty much the same as the normal web devtools.
    - city41 7y ago
      There is also ndb for a very similar effect. What I really like about ndb is it works in front of just about anything, for example `ndb yarn test` https://github.com/GoogleChromeLabs/ndb https://github.com/GoogleChromeLabs/ndb
  - llcoolv 7y ago
    Reference implementation almost exclusively refers to behaviour and not performance. For example reference implementations of JSRs have very very rarely been usable/used in production.
- TomMarius 7y ago
  > graphql-js is the reference implementation of GraphQL, so it's not any random library. I always expect the reference library to be optimized for correctness, formal proofing, brevity, simplicity and clarity, not (compilation nor execution) speed.
xwowsersx 7y ago
I hear your point and it's true that you can't point the finger at GraphQL qua GraphQL, but that's sort of by definition since gql in itself is, as you say, just a spec. But, and I'm not saying this is the case, if every implementation of gql has major issues, it's not really fair to say "but but the spec itself is fine". As programmers, we aren't working with the spec.
- jensneuse 7y ago
  It's technically possible to achieve the result op wants in sub millisecond time. However I'm not sure if Node.JS is the right stack for this. You'll have to carefully avoid object creation and reduce garbage collection overhead.
deleted 7y ago
[deleted]

deleted 7y ago

[deleted]

ctvo 7y ago

You focus on and make assumptions it's indexed rows and that ~20ms average for a database call is "suspicious" but you're not concerned about the 400ms flamechart for graphql-js doing validation shown in the thread? graphql-js is the reference implementation of GraphQL, so it's not any random library.

jensneuse 7y ago
The graphql-js library focuses on correctness, not on performance. Facebook doesn't invoke it at runtime, only at built time. They use persistent queries only. If you want a high performance server runtime I wouldn't use Node.JS. Especially for a complicated task like validating and resolving a GraphQL query Node.JS is the wrong tool. It's too high level to tweak hot paths and optimize the garbage collector. So no, I don't think the flame graph is suspicious. In my language of choice (go) I could drill down memory and CPU consumption for each line of code to find the bottleneck. Maybe this is possible for Node.JS too, I don't know the tooling so well. I would suggest that if such tool exists a detailed flame graph of the Node.JS application might help understand the issue.
- swyx 7y ago
  iirc fb doesnt even use graphql-js much? the whole thing was embedded in PHP Ents . graphql-js was written purely for the opensourcing. ofc things may have changed somewhat in recent years but i doubt if
  - lowdose 7y ago
    No I heard they still chew a lot of bubblegum over there.
  - eshyong 7y ago
    Is PHP Ents a type of webserver FB uses?
    - sophiebits 7y ago
      Ent is a (proprietary) database wrapper library resembling an ORM,* but I don’t believe Facebook’s GraphQL server infrastructure is tied to Ent at all. * Though Ent’s creators emphatically claim it is not an ORM, that phrase does give you a rough but directionally-accurate idea of what it is.
      - swyx 7y ago
        ah ok. sorry for potential misinformation, i glean only what i can from being a casual outside observer.
- hn_throwaway_99 7y ago
  OP is using Apollo Server, which is by far the most common server implementation for GraphQL. It may well be there are issues specific to Apollo, but it's definitely worth getting to the bottom of based on how widely used Apollo is. There is nothing in the posts that identifies NodeJS as the culprit, and based on the info I'd be very surprised if it was. It seems most likely that the type validation is what is taking so much time. But then again, strong types are one of the main benefits of GraphQL. If anything, I've found Node to be one of the easiest and most "natural" server languages for GraphQL, and I have implemented GraphQL servers in Node, Java and Python.
  - deleted 7y ago
    [deleted]
  - dnautics 7y ago
    Have you tried elixir's absinthe?
    - deathtrader666 7y ago
      I'm curious to find any performance comparisons between Elixir's Absinthe and Hasura, on a Phoenix app.
      - dnautics 7y ago
        I would be extremely (but prepared to be) surprised if Phoenix + Hasura were faster in terms of latency than Phoenix + Absinthe, since one has to enter and exit two vms and the other doesn't, unless you're suggesting the frontend issue graphql results directly to the hasura backend, bypassing phoenix.
        deathtrader666 7y ago
        Two ways one could test - 1] REST client <-> Hasura <-> Phoenix 2] Phoenix-generated HTML <-> Hasura <-> Phoenix
  - 7y ago
- foota 7y ago
  This comment neglects the fact that people can and do use node in situations where performance is important, and 400ms is especially egregious. Having the obvious path for using graphql in js server side perform terrible is problematic.
  - andrewingram 7y ago
    For a point of comparison, when I was using graphql-js around 3 years ago, I was benchmarking things pretty carefully and the main bottleneck wasn't graphql-js -- I had comparable (or faster) response times to equivalent existing hand-crafted JSON endpoints. But if you're fetching a lot more data than you need for a typical UI, you might run into bottlenecks.
    - foota 7y ago
      Yeah, it sounds like the poster is having issues with their deep hierarchy causing lots of unnecessary object creation? I'm still surprised it had that much overhead though, as I generally think of node as being relatively competitive with Java outside of heavy computation.
      - 83hajfjeijg 7y ago
        A deep hierarchy? 3 levels? Really? Lots of unnecessary object creation? We're talking about a total of 1600 fields. If that's considered a lot then GraphQL is in worse shape than I thought.
      - andrewingram 7y ago
        Deep queries aren't usually a problem as it's usually just waiting on I/O, it's wide queries that are a bigger concern. I just remember that CPU load was very low compared to other metrics, so I mostly focused on fixing memory (which was related to the file descriptor issue) usage. One issue I see a lot of (which happens to be part of the problem in this case) is people overfetching data on their list UI (e.g. search results) so that the detail page data is already in the client side store. But this is usually a premature optimisation and ends up causing more problems than it solves.
- sciolistse 7y ago
  Regarding profiling in Node.JS (in case anyone who is interested is unaware,) if you start your application with the "--inspect" argument and then open devtools in chrome/chromium there's a little node icon that shows up in the top left corner. If you click on that you can get performance flame graphs / tables, memory profiling, and there's also a REPL for the process, as well as a list of loaded source files so you can set breakpoints through there if you like, as well as modify the files on the fly if you need something more for debugging. It can be very useful, and works pretty much the same as the normal web devtools.
  - city41 7y ago
    There is also ndb for a very similar effect. What I really like about ndb is it works in front of just about anything, for example `ndb yarn test` https://github.com/GoogleChromeLabs/ndb https://github.com/GoogleChromeLabs/ndb
- llcoolv 7y ago
  Reference implementation almost exclusively refers to behaviour and not performance. For example reference implementations of JSRs have very very rarely been usable/used in production.
TomMarius 7y ago
> graphql-js is the reference implementation of GraphQL, so it's not any random library. I always expect the reference library to be optimized for correctness, formal proofing, brevity, simplicity and clarity, not (compilation nor execution) speed.

xwowsersx 7y ago

I hear your point and it's true that you can't point the finger at GraphQL qua GraphQL, but that's sort of by definition since gql in itself is, as you say, just a spec. But, and I'm not saying this is the case, if every implementation of gql has major issues, it's not really fair to say "but but the spec itself is fine". As programmers, we aren't working with the spec.

jensneuse 7y ago
It's technically possible to achieve the result op wants in sub millisecond time. However I'm not sure if Node.JS is the right stack for this. You'll have to carefully avoid object creation and reduce garbage collection overhead.

deleted 7y ago

[deleted]