[Discussion]: Incorperating GEWIS-specific code into the source

[JustSamuel]

Back in the day, when SudoSOS was still driven by hopes and dreams, there was an idea to deploy SudoSOS outside of a GEWIS context. This idea is the reason why all GEWIS-specific code is under /src/gewis, and SudoSOS is expected to survive even if you remove the entire folder.

This idea—that you can remove the GEWIS folder—holds up pretty well:

• The code is tested without the GEWIS code.
• The source code is agnostic to most GEWIS-specific logic.

The biggest downside is that, to facilitate this, a lot of code is injected at runtime:

sudosos-backend/src/index.ts

Line 156 in 9d229d3

Gewis.overwriteBindings();

This is highly nontransparent and annoying. I already created an issue to slightly improve this (#341), but that doesn't really address the root cause:

Creating software personalized to GEWIS while remaining GEWIS-agnostic is difficult.

Another example is that we are unable to return GEWIS IDs for most "regular" endpoints. In some cases, we inject code that does return GEWIS IDs, but we can never include this in the Swagger documentation. Being unable to include it in Swagger automatically means that our responses do not match the spec—by design—which, in my opinion, is a code smell.

The discussion, therefore, is: Do we let go of the dream that SudoSOS will ever be deployed outside of GEWIS and simply merge the GEWIS code into the main source? This would streamline the code and improve compatibility.

[Yoronex]

This has indeed been a recurring topic for discussion. I personally feel that the runtime bindings are the most ugly artifact we have to get rid of. If you want to, we can change the design decision 180 degrees and make SudoSOS GEWIS-specific instead of agnostic, but I don't think that is necessary.

Let's take a step back and think about the core problem the GEWIS module tries to solve. It's purpose is to link SudoSOS to GEWIS. How do we do this linking? With membership IDs. The format of these IDs is GEWIS-specific, but the concept is not. Every association works one way or another with member IDs. You can even see it as a foreign key to the association's membership database.

So let's say that we introduce a new system requirement, namely that MEMBER users have a membershipId attribute. Well, this is something we already implement, so that's a plus. Then, what do we use this ID for? Primarily for authentication and identification. Well, we can still implement these with this new requirement, and moreover, some of them (like identification) will probably become even easier!

With such a new system requirement and the deprecation of the GEWIS module, we can still make the system somewhat modular, if we take inspiration from the Hubble-Aurora project. By using things like environment variables or system settings, we can dynamically enable/disable functionality like authentication methods using feature flags or strategy patterns. In my opinion, this could make it even easier to integrate SudoSOS in different environments.

However, I think the most important thing is that we make our interfaces static. They should NOT change based on the presence or absence of modules/environment variables/settings. Incorporating a membership ID in all responses will make frontend development also much easier, and I do not believe it will have many negative consequences, as it should be an optional attribute anyways.

[tomudding]

We have already discussed this privately, but I share @Yoronex's view on this.