2 ms·
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
by 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 agoYou'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.