Is there any chance in the future the ESI API will adopt GraphQL?
Also https://www.howtographql.com/
I think this would greatly simplify and decouple client design.
It’s the future 
You could run a dual interface and have it run on top of the existing REST interface until people migrate to GraphQL and it is fully GraphQL implemented.
Why? Simple “It’s the future” is not quite enough.
I think it is quite clear the benefits of using GraphQL over REST, it is clearly shown on the two sites I linked.
If you are a developer at any capacity consuming or producing API’s it is well worth spending the time and reading into it.
If I had a choice of consuming the old form REST interface for Eve or proxying a GraphQL interface over it, I would prefer to put effort into the latter form if they did not produce an official GraphQL interface.
Representational state transfer (REST) was congured up around the year 2000 by Roy Fielding in a dissertation. We have moved on into richer more capable API methods, such as GraphQL.
REST is too bloated and archaic compared to GraphQL and the agility and iteratability. Also it is client query based rather than server representational structure based. It allows far simplier and richer clients and queries than REST provides without cumbersom acrobatics.
REST under or over provides data, inefficient, leaky, inflexible and too rigid.
A rough analogy is like comparing a procedural function call, to a data query. The data query is more natural and flexible.
You can perform less queries, have a less chatty client, and only result data that is requested rather than missing gaps or providing too much data (leaky), REST also typically requires a multiude more calls than GraphQL needs as you simply query what you need in less calls (there is only one endpoint vs umpteen endpoints in REST).
This is something that they can look at as a “lab” experiment. I would prefer CCP create the endpoint and type schema rather than me proxy it with my own type schema.
If we get anything new, we will get protocol buffers, as that is what eve uses now.
See: Introducing Quasar | EVE Online
Atm. even critical ESI bug fixes takes months to get fixed.
Stuff like isn’t realistic at all…
The major advantage of GraphQL is the fact you get what you query for, no more, no less. You don’t just get what the server feeds you at an endpoint or data structure.
That’s the strength of GraphQL, it’s basically a data query and that may vary per client application as each client is doing something different, it’s VERY versitile and agile and also can be done without strict versioning on the API.
It’s not about why or why not GraphQL is great or not. It’s about CCP dev time being used for game stuff not API stuff, because, that is how you earn money.
If you want to use my apps, you have to pay to get your own devkey from CCP. You won’t be using mine, my apps won’t come packaged with any PKCE for my devkey, load your own.
As for compressibility (which is what protobuf is, a lean binary message protocol), HTTP with GZIP will do decent compression on the wire for the GraphQL.
They may use gRPC and Protobuff internally, but for public client development, GraphQL would be more suitable imo as they don’t control the public client development projects and needs.
They can use a rigid query structure internally because they control BOTH participants and can keep them in development sync, with public clients, they don’t control that and thus need the decoupling agility.
This is a case where one size does not fit all, gRPC and Protobuff when they control all participant projects, GraphQL for public project interfacing. Caching will be heavily used anyway as far as performance goes at their end for our queries.
To be clear we’re not arguing against the benefits of GraphQL, but the fact of the matter is this just isn’t something that is going to be supported within any reasonable time frame, if ever.
Well, sometimes it’s healthy to have a “lab” side project for engineers that may turn into something fruitful.
Sure, but the unfortunate reality of things is their side project is keeping ESI online. As much as it would be nice to have, it’s just not going to happen.
Well as it stands to do a thing like this is a bloated mess of inefficient calls and leaky data bloat
ESI (REST)
{name, security status, .. 11 total, 2 needed} <- /characters/{character_id}/
{solarsystem id, .. 3 total, 1 needed} <- /characters/{character_id}/location/
{online, .. 4 total, 1 needed} <- /characters/{character_id}/online/
{ship_name, .. 3 total, 1 used} <- /characters/{character_id}/ship/
4 endpoints called, 5 fields needed, 21 fields returned
GraphQL
/GraphQL endpoint
{
character {
name
securitystatus
online
location {
solarsystem {
name
}
}
ship {
name
}
}
}
One endpoint called, only relevent fields queried and answered in a more natural structured way
Again we’re not saying we don’t want GraphQL, just that it’s not going to happen anytime in the foreseeable future. So you’re just going to have to have deal with the REST API.
Well, I think it’s also important to make a discussion out of it and make it visible as an ask by third party developers and the benefits of it.
Perhaps the CSM can raise it?
Feel free to create an issue for it: Sign in to GitHub · GitHub. But be prepared for it to sit open for years.
We’ve (EVE Partners, and team ESISD), have been bringing up the multiple ESI bugs for quite a while and even then it takes months for them to be resolved, if they do at all, as @Golden_Gnu pointed out. At this point it’s essentially out of our hands until CCP decides to devote more resources to ESI.
Don’t forget also that you are putting all of the data processing on CCP side, not on our side.
At the moment, ESI is set up in a way that reflects the way data is stored on CCP side. If we want to drill down into the data that is on us to provide the processing power.
What you are suggesting is putting extra load onto a system that already struggles to stay afloat as it is.
While ESI is a nice tool to have, it is not essential to play the game and it is provided by CCP at cost to them. It is unrealistic to expect them to pour more resources into that system to make it easier on us.
I get you have not worked with ESI very long, and therefor doesn’t know how things work, with ESI and how CCP are handling it, but, please try to listen a little bit to what people are saying. It won’t help you to win an argument with us. Nothing you want to change about ESI is going to change by making threads on this forum, It’s literately like screaming at a wall, as CCP wont’ even read it on this forum. Debating with us is just as pointless, as we have no way to change anything either (I wish we had). The place where there is a (regrettably, very small) chance for something you request to be implemented, is the GitHub issues. It’s very sad, but, it is how it is.
zoiie doesn’t like the fact that they have to pay to use CCP’s dev key plain and simple… they expect to have all their stuff handed to them, without ever paying for it…
all other 3rd party devs have done it.
You could always build your own GraphQL Interface on top of ESI. Each of the resolvers would just execute HTTP Requests too ESI for the data that you are requesting. Problem fixed.
ESI is a data layer API that gives us, the third party devs, access to in game data. It has no business logic and is not meant to act as an API that a frontend consumes. That is why the data is structured the way it is.
Love how signing up to GitHub is too much but using a Facebook-created data query language is just fine!
Jokes aside, REST is more widely known and supported, and like others have said, there’s no need to waste developer time (money) on embracing today’s new hip framework.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.