Refactoring of the backend

[dawidgarus]

@flavioislima Hi. You wanted to hear my option on refactoring of the backend and moving to functional programming, so I starter this discussion.

So here are my two cents:

1. The codebase is in dire need for some major refactoring.
2. Personally, I don't have strong preferences for functional or object oriented programming. Use the best tool for the job and both styles are adequate if used properly. I just hope it's not just switching to functional for the sake of just switching to functional programming.
3. That being said, IMHO refactoring of BE right now is not possible because there's no actual BE. The UI and business logic are very much intertwined. Unless that gets untangled first, you'll have a hard time with refactoring. Especially since the code has many side effects...

My suggestion:
Before anything else is done, the app must be divided into 3 parts which communicate with each other using well defined APIs:

1. UI - everything that runs inside browser window. It should be completely electron agnostic, except for a thin abstraction for the UI API which will facilitate commutation with BE. This also means no direct access to the store. Only that will allow us to write automated integration tests with stubbed API and add easily new features in the future without the fear of breaking anything.
2. Runners - bridge between application and launchers. They too should be 100% electron agnostic. They should be written in a way that someone could publish a runner in npm repository, you add it as a dependency and add one line of code to register the runner in the app and there you go. This means that they also shouldn't have access to application store. This should also allow us to mock them for automated tests and unit test them individually.
3. Core - The actual BE. Caches and aggregates data from runners and sends it to UI. Handles actions from UI and dispatches them to runners if needed. Manages all the data and configurations.

Only then we will what further refactoring needs to be done.

This architecture will also open the doors for implementing other features to be implemented in the future, like running application headless in the background, adding a command line interface, adding support for other launchers or even adding games manually.

[flavioislima]

Yes. Completely agree with all your points.
We made some bad architectural decisions without thinking about how much Heroic could grow and some past contributions should have been studied more carefully as well.

I believe this is not something we will do overnight, it needs to be planned to go in the right direction.
Especially, as you said, if someone wants to add a new runner, should be as easy as installing the package and adding a new line of code.

What I don't like about OOP and I think it was a bad decision on our end to move to it, is basically the boilerplate of writing a lot to create some basic implementations and the pain that It is to mock the classes to write the tests.
I believe functional could make it easier to reach the things you said as well.

[dawidgarus]

IMHO, completely switching programming paradigm is a change that needs to be sufficiently justified. To paraphrase Carl Sagan: "extraordinary changes require extraordinary reasons".

What I don't like about OOP and I think it was a bad decision on our end to move to it, is basically the boilerplate of writing a lot to create some basic implementations and the pain that It is to mock the classes to write the tests.
I believe functional could make it easier to reach the things you said as well.

I personally don't find it true at all. Testing OOP is easy. Especially when employing DI pattern. That's its whole thing - ability to provide alternative implementation. The boilerplate is not a boilerplate - it's the aforementioned well defined contract that is necessary.
I would like to see some examples what could be simplified with functional approach.

[flavioislima]

Yes, I know that there is no easy answer for that. It is just a thought.
But we have other priorities and optimizations before thinking about a huge refactored since we have other features that things to fix, etc.
Lets get back to it in the future then.