3 ms·

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 A

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.

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.