search

Microsoft-community / Dotsimus-TS

1 stars 1 forks source link

Libraries <=> Abstract interfaces <=> Dotsimus code #4

Open lost-in-action opened 3 years ago

lost-in-action commented 3 years ago

Abstraction

Bridge

For portability reasons, it's better to avoid using libraries like discord.js everywhere in the code, instead, rely on abstract interfaces for Dotsimus, and implement those abstract interfaces properly (implement what needed). discord.js should be used inside implementations of these interfaces and nowhere else: these interfaces act as a bridge between the libraries and dotsimus. Currently only discord.js have to be bridged (it's the only external module) since it's a pretty big one, internal nodejs modules are fine (and small modules too).

Learn more about bridges here:

Reasons

The primary reason is for easier portability. Here are good reasons to rely on bridges instead:

  1. If discord.js discontinues (chances of it are very low but it's better to plan things in advance, this happened with discord.py) or changes, recovery should be done easily and quickly through abstract implementations: this means that most part of the Dotsimus code base remains untouched, only the abstract implementation have to be modified in order to switch to a new library
  2. If the Discord platform ever shut down, why not switching to another platform that supports bot? Revolt, Guilded, or anything else: switching to any of these platforms could be done quickly
  3. Can use unit testing: the trick would be to implement the interface to fake events and responses
  4. Probably a dumb idea, but who says abstract interfaces also says multiple implementations, which mean... Multi-platform bot, this is just an idea of course

Overall if something ever change in the Discord API and/or in the library, then it shouldn't affect the entire codebase, those are ideas. Hope you understand 😃

Jasius commented 3 years ago

Certainly, an interesting idea, I personally never had to do abstractions to this level thus I don't really know what hurdles this entails and how much extra complexity it adds.

Jasius commented 3 years ago

and I like the Golden Bridge joke there ;)

lavgup commented 3 years ago

Regarding unit testing, it's a tough area to dive in, and most implementations I've seen do it just for the sake of having tests and not to speed up/help development. It's probably better to not mock the API (leave that to the library developers), but to test the bot core in that everything works fine. This could branch down to utilities such as message formatters and case helpers.

Also, about your main point about using library functions, I somewhat agree. It is probably best to not use high-level interfaces too much but we shouldn't sacrifice general code quality just in the chance that discord.js may be discontinued in the future (also keep in mind that discord.py only had one core maintainer, whereas discord.js has like 4). Just for the record, discord.js helpers such as @discordjs/builders and @discordjs/rest can be appropriately be used as they are library-agnostic should we ever need to switch libraries.

lost-in-action commented 3 years ago

Regarding unit testing, it's a tough area to dive in, and most implementations I've seen do it just for the sake of having tests and not to speed up/help development. It's probably better to not mock the API (leave that to the library developers), but to test the bot core in that everything works fine. This could branch down to utilities such as message formatters and case helpers.

Also, about your main point about using library functions, I somewhat agree. It is probably best to not use high-level interfaces too much but we shouldn't sacrifice general code quality just in the chance that discord.js may be discontinued in the future (also keep in mind that discord.py only had one core maintainer, whereas discord.js has like 4). Just for the record, discord.js helpers such as @discordjs/builders and @discordjs/rest can be appropriately be used as they are library-agnostic should we ever need to switch libraries.

I agree, and actually after some thinking, I don't think the abstract interface is the best idea, it's time-consuming and can get complex when trying to support various libraries. So maybe, Multi-layered software architecture as a replacement for abstract interfaces? (dotsimus seems to be doing this on some part of the code anyway) https://en.wikipedia.org/wiki/Multitier_architecture