GraphQL interface as an alternative/future to REST for public client development.

[ghost]

Feature Request

GraphQL interface as an alternative to REST for public client development.

It would allow us to have more powerful queries to a single endpoint
Reduces amount of requests made to obtain required and aggregate data
Simplify code
Decouple client code from the server rigid endpoint and response structure
Prevent leaky data bloat in responses
Allows query introspection
Reduce overhead on the server with only one endpoint and only returning the data requested, no more, no less
Remove throwing away unused data from rigid server responses, data/bandwidth waste
Remove versioning overhead
Can be run on top or beside the current REST as a migration or dual interface strategy
Can be cached for performance both on clients and server side

See the following links for more details

https://graphql.org/
https://www.howtographql.com/

Use case

Third party public developers with their own individual requirements and timelines

Authentication

Existing authentication methods can be used

Example return

The response is determined by the client requested GraphQL and schema

Checklist

Check all boxes that apply to this issue:

• Feature request description is provided
• Use case exists
• Feature requires a new route
• Feature adds data to existing route
• Feature requires new auth scope
• Feature can reuse existing scope
• Feature does not require auth
• Meta feature, applies to all routes

[ghost]

As an extra note, GraphQL would be a cleaner solution than batching REST queries to a new batch/bulk endpoint as there is still the problem of data over-fetching even though it results in less network roundtrips.

[kennethjor]

FWIW you could probably implement this yourself. Apache TinkerPop is a graph database engine that has a number of providers. It should be possible to write a custom provider to query the ESI for you. TinkerPop uses Gremlin rather than GraphQL, but the idea is the same. I also have a daily scrape of the ESI available for download. You could add this for fast static data access.

I know it doesn't resolve the issue, but it's an idea.

[ghost]

FWIW you could probably implement this yourself. Apache TinkerPop is a graph database engine that has a number of providers. It should be possible to write a custom provider to query the ESI for you. TinkerPop uses Gremlin rather than GraphQL, but the idea is the same. I also have a daily scrape of the ESI available for download. You could add this for fast static data access.

I know it doesn't resolve the issue, but it's an idea.

This is derailing the issue ticket as we all know GraphQL can be implemented on top of REST by anybody.

This ticket is directed to CCP to provide a GraphQL interface, not third parties. Please stop derailing tickets.

Also proxying GraphQL on top of REST won't solve the data field over-fetching issue and network round tripping issue (without REST batching).

Another issue could be mixing of resource cache timings when amalgamating the interface. Whilst ESI is not rate limited it is error limited (due to the cost of serving errors).

One feature that may benefit is GraphQL's subscriptions for serving a stream of data rather than client polling, that would require a persistent full-duplex TCP connection (using IETF RFC 6455 Secure WebSockets).

[cvweiss]

For reference: https://forums.eveonline.com/t/esi-adoption-of-graphql/346733

This has been discussed and determined to very likely not happen as GraphQL doesn't fit the structure of Eve.

I could make a few points against your italicized word soup, but I feel it would be pointless. A discussion of the pros and cons of implementing GraphQL vs keeping the current implementation or making suggestions is not derailing the issue.

How will increasing processing power (expensive) on CCP's servers for custom GraphQL responses, which cannot be easily cached, benefit CCP over simple REST responses that require minimal processing power using cheap network bandwidth that is cached at the CDN?

[ghost]

GraphQL can absolutely be cached, both client side and server side.

It is even discussed on the GraphQL site here https://graphql.org/learn/caching/ and elsewhere on the web.

And yes, interjecting with "do it yourself" responses are not constructive to this actual ticket which is for CCP to decide on an official GraphQL endpoint and type schema.

You can disagree, but stop derailing the ticket with DIY solutions/hackjobs we all know about. This ticket is to track an official implementation, not an Eve Online discussion thread that belongs in the forum.

GraphQL also reduces the network calls, the only way to do that with REST is via a batching endpoint which is not existing on ESI. GraphQL would actually lighten the bandwidth required, that was the entire point of its creation at Facebook a decade ago and they serve and cache at scale.

GraphQL would be far more suitable then gRPC/Protobuff for third party public client projects that CCP does not control requirements/needs/timeline for. gRPC/Protobuff is certinally suitable for their internal use where they control all projects, it is not for third party public projects they do not control. One size does not fit all, especially when it comes to third party public interfacing, GraphQL would allow better decoupling and flexibility/optionality for the varied projects CCP does not maintain or control.

[kennethjor]

To keep the thread on-topic, if this is considered, I'd cast my vote for it being an additional layer for people who want it, with the existing REST API remaining in place.

[ghost]

To keep the thread on-topic, if this is considered, I'd cast my vote for it being an additional layer for people who want it, with the existing REST API remaining in place.

To have an efficient wrapper CCP would need to implement a batching REST endpoint for the exercise to be worthwhile otherwise you gain no reduction in network bandwidth due to repeated REST calls. Your proposed solution (DIY REST proxy wrapper) will not work efficiently and there is the problem still of over-fetching of data fields that get discarded if not in the query.

This is better implemented by CCP who can do it right(er) than a third party wrapper on the existing REST endpoints.

[DianaOlympos]

This issue is not progressing. Thanks for logging it and it will be kept around for now in case people want to work on it.

Have a good day