GraphQL API
This will allow to do more with fewer requests and in a consistent way.
This will solve issues like this: https://support.discordapp.com/hc/en-us/community/posts/360041483031-Bulk-Reactions
Update:
You guys downvoters are short-sighted!
I have nothing against REST API. It's simpler and it's already working. GraphQL usually can't replace it completely.
But GraphQL can be introduced gradually alongside with REST API.
And there are good reasons why graphQL was created - there are tasks that it can do better that REST API.
I wrote this request after I wrote complicated code just for mere goal of reading all reactions from a given user under a given message (have to do a separate request for all existing reactions). This is a shortcoming of the existing API. Same for the absence of bulk emoji additions.
These operations should be trivially described in GraphQL. As well as any other stuff that authors of REST API never thought of.
Update 2:
https://github.com/discordapp/discord-api-docs/issues/182#issuecomment-262388833
> Bulk adding reactions to use them as buttons is not a use-case of the API we're wanting to support/encourage.
> There are talks internally of adding an API to add buttons - but we don't have any official plans yet.
I've no idea if the plans were solidified in the last two years. So far we just stuck in the situation where slowed down reactions is all we can use.
It probably worth to vote for something like https://support.discordapp.com/hc/en-us/community/posts/360040066771-Embed-Buttons
-
Discord's API is based around two core layers, a HTTPS/REST API for general operations,...- Discord's API Documentation
I'm sorry but it doesn't make technical sense to add an additional API purely because you don't like REST. It'd be difficult to maintain and make stuff a lot more difficult on their end. Just use the brilliant API that is already available :)
Source:
https://discordapp.com/developers/docs/reference#api-reference
2 -
updated
1 -
updated again
1 -
It's so much more work to maintain two APIs than it is to maintain just one, and it'd only go to waste. I seriously doubt there'd be a significant enough amount of users to justify maintaining an entire second API; the popular libraries that already exist would have to be entirely rewritten to use it.
0 -
Finally a valid concern. Thanks. I'm leaving this, albeit downvoted, request so there is a place to gather all thoughts on the matter.
I don't think having GraphQL alongside with REST has much of overhead. I think it will be easily justified once the Discord developers find a use of it's flexibility for themselves. Although I haven't had an experience of supporting it by myself - dunno if my expectation of it is too optimistic or not.
I believe it won't take long for actively supported bot libraries to expose new API endpoints if there are quality GraphQL libraries available for the language they are written in.
1 -
Another benifit of using graphql is that it is, by design, self documenting. The documentation of the api will be a lot easier to keep up to date with the current api versus the very manual documentation of today (which tends to end up very out of date or confusing). In general GraphQL would be a better alternitive since you only need to ask for what you want. It will solve many an issue with hundreds upon hundreds of guilds with all their information getting fed to a bot that only cares about one specific piece of information,
1 -
I would love a GraphQL API but, like others have said, it might require extra work for the API devs. However, I may have found a possible solution:
https://graphql.org/blog/rest-api-graphql-wrapper/
I'm sure it could be implemented.
0 -
I agree here, graphql makes developing cool applications around discord a lot easier. I currently have some bots where i am fetching tons more data than i will ever need. I don't see any problem in a community built graphql wrapper around the api. If you guys are interested i see no problem in doing it myself.
0
Please sign in to leave a comment.
Comments
8 comments