Discord.net: v3: user poll - how are you using this library?

[foxbot]

As we decide how to proceed with v3's design, we would appreciate some feedback as to what kinds of unique cases the community is using this library in their projects.

If you are using the bot in a traditional design (as most bot examples demonstrate, e.g. strictly relying on socket entities, not using interfaces), please just thumbs-up this post; I'm more interested in edge cases we should be addressing and how we can make normal bots easier to develop, rather than how many people are following the same generic pattern.

Bear in mind that we may not actually change anything with regard to the design, though the nature of v3's dependence on Wumpus entities may inspire us to strip some things out.

[cryy]

I use it both as a mainframe and for a website integration. For the website integration, I use more of the OAuth2 side, however reducing the amount of requests I need to make to Discord is almost impossible due to Discord.Net's dependency on it's own entities. I combine both the socket features to update user's screen in realtime to whatever occurred in their guild and the rest features, e.g getting a user whom the bot does not share. Would like to see some more improvements to OAuth2 integrations. Due to Discord.Net's nature of depending on it's own entities, I guess improvements like allowing the user to call an oauth endpoint with just an id, right now, is impossible.

[Kein]

Incorrectly in every possible way.

[igorquintaes]

I had some challenges to use Discord.Net based on my needs. To simplify what it does, it is a bot that users can register an alert when a new manga chapter is released. So It needs the default bot instance and a job that runs each XXmin checking if there is some new release and alerting the people when there are.

1 - I haven't found any clear example that I could run two instances of the same bot in parallel in the same application, what forced me to create a WebJob bot instance that ignores any message request.

2 - I don't find any support neither example to multilanguage support. One of the commands change the reply message language, and I had to rewrite all Attributes to support a ResourceManager than a constant string, used in a reply message

3 - Write unit tests is a pain. The actual lib design is coupled at the point you need to create a new ModuleBase only to mock some calls to props and methods, making a new of those as virtual. Not only that, you need to create a mock of your own class module and make the testing method and call the base method if you want to do a real unit test. Maybe it can have an example inside Discord.Net how to do but mainly needs a new development approach to solve the coupled issue.

4 - Is is not clear, like other libs as Asp.NetCore, how scope is registered inside a message request. Initially, libs that provide us an in-out channel of requests (like controllers in web applications) are default inside a scope, and there is no need to create it manually. Basically is how each request has its own scope, and you can or not use it. In Discord.Net you have to declare explicitly that scope.

[xSke]

I'd love some way of accessing the API directly, bypassing the model structure. A problem situation I encountered in practice was that I had a channel/message ID stored in a database, and I wanted to delete that specific message from the ID. With API access I could just call the delete message endpoint, but instead I had to fetch the message object itself (1 api call) then delete the message with the Delete() method (1 more api call). I could just call the endpoint directly via HTTP, but then I miss out on, say, ratelimiting integration.

Additionally some way of accessing entities' raw JSON format would be useful, either by having [JsonProperty] annotations directly in the models matching the original layout 1:1 (DSharpPlus-style) or by being able to create a class based on that that I can then Newtonsoft.Json on (I assume just storing the JSON string itself would be too memory intensive to be practical).