4 ms·

Juniper - GraphQL library (+ Server if you want it to) written in Rust: https://github.com/graphql-rust/juniper https://github.com/graphql-rust/juniper We’re u

Juniper - GraphQL library (+ Server if you want it to) written in Rust: https://github.com/graphql-rust/juniper https://github.com/graphql-rust/juniper We’re using Juniper in production as a central API for other internal services. The performance of literally any other GraphQL server is just hilariously slow compared to it. We previously used Node GraphQL and were happy with it, but at some point we needed more raw speed. (edit: just to make it clear -- I'm not affiliated with this project)

hrpnk 8y ago
Do you have any benchmark results? I see none linked in the repo.
e12e 8y ago
This will come off as a bit snarky, but I'm really just trying to be direct. It's always great when people share their hard work! > The performance of literally any other GraphQL server is just hilariously slow compared to it. Is the same kind of fast as in getting the data from the sql server takes half a second, but x then renders the response in 20 ms not a slow 80 ms (520 vs 580 ms response time to the client)? I mean, I unless your data is in an in-memory in-process database, it comes from the network to the graphql server, which acts as a proxy for the client? Which makes a claim of being a lot faster than eg nodejs interesting - but also somewhat surprising.
- KenanSulayman 8y ago
  There's a lot to this. First off, I was talking about internal services -- the "this is essentially a very expressive interface to a database" kind of GraphQL API. There's no 500ms network overhead. In fact, there's not even 20ms network overhead. Those 50ms are pretty substantial in this setup. For most GraphQL API requirements in terms of performance there's no real value in using Rust if you're not already very proficient in it. That said, 520ms is extremely pessimistic for most GraphQL servers. The API to a project I'm running is built using the Node / Apollo GraphQL server and its response times are well under 90ms; that's with a CDN in between: https://api.psychonautwiki.org https://api.psychonautwiki.org. [server in Germany; US mileage may vary] (btw -- I'm not affiliated with Juniper)
  - e12e 8y ago
    Thank you for clarifying. As for the 500ms I wasn't thinking only network overhead, but also things like complex sql queries with lots of joins etc. And maybe on top of that going through a json-rest/soap endpoint: Client > graphql server > rest endpoint 1..3 > [sql server, document db, key-value store] Where the graphql server takes a query, fetches and merges resources, and sends the result back to the client. (and as you mention, maybe rest and rest are external services) If it's just: Client > graphql > documentdb (since your link mentions wiki...) - I'm not sure I see that graphql is a great benefit (but I'm perfectly open to that being wrong; as I said, I've only just begun looking at graphql).
    - KenanSulayman 8y ago
      You're much correct about the performance implications of complex external queries. 500ms to 600ms is very realistic in that case. But I assume that you can always cache specific parts of the external requests, although the efficiency of that is very dependent on the homogeneity of your requests. And you're very right that GraphQL isn't very smart for a wiki (besides being a fancy replacement for REST). PsychonautWiki is documenting the effects (and dosage, durations, ...) of hallucinogenic substances; GraphQL allows people to easily query for substances with similar effects, or substances from the same class, .., all in a single request. Also you get type checking and field selection for free.

hrpnk 8y ago

Do you have any benchmark results? I see none linked in the repo.

e12e 8y ago

This will come off as a bit snarky, but I'm really just trying to be direct. It's always great when people share their hard work! > The performance of literally any other GraphQL server is just hilariously slow compared to it. Is the same kind of fast as in getting the data from the sql server takes half a second, but x then renders the response in 20 ms not a slow 80 ms (520 vs 580 ms response time to the client)? I mean, I unless your data is in an in-memory in-process database, it comes from the network to the graphql server, which acts as a proxy for the client? Which makes a claim of being a lot faster than eg nodejs interesting - but also somewhat surprising.

KenanSulayman 8y ago
There's a lot to this. First off, I was talking about internal services -- the "this is essentially a very expressive interface to a database" kind of GraphQL API. There's no 500ms network overhead. In fact, there's not even 20ms network overhead. Those 50ms are pretty substantial in this setup. For most GraphQL API requirements in terms of performance there's no real value in using Rust if you're not already very proficient in it. That said, 520ms is extremely pessimistic for most GraphQL servers. The API to a project I'm running is built using the Node / Apollo GraphQL server and its response times are well under 90ms; that's with a CDN in between: https://api.psychonautwiki.org https://api.psychonautwiki.org. [server in Germany; US mileage may vary] (btw -- I'm not affiliated with Juniper)
- e12e 8y ago
  Thank you for clarifying. As for the 500ms I wasn't thinking only network overhead, but also things like complex sql queries with lots of joins etc. And maybe on top of that going through a json-rest/soap endpoint: Client > graphql server > rest endpoint 1..3 > [sql server, document db, key-value store] Where the graphql server takes a query, fetches and merges resources, and sends the result back to the client. (and as you mention, maybe rest and rest are external services) If it's just: Client > graphql > documentdb (since your link mentions wiki...) - I'm not sure I see that graphql is a great benefit (but I'm perfectly open to that being wrong; as I said, I've only just begun looking at graphql).
  - KenanSulayman 8y ago
    You're much correct about the performance implications of complex external queries. 500ms to 600ms is very realistic in that case. But I assume that you can always cache specific parts of the external requests, although the efficiency of that is very dependent on the homogeneity of your requests. And you're very right that GraphQL isn't very smart for a wiki (besides being a fancy replacement for REST). PsychonautWiki is documenting the effects (and dosage, durations, ...) of hallucinogenic substances; GraphQL allows people to easily query for substances with similar effects, or substances from the same class, .., all in a single request. Also you get type checking and field selection for free.