Clean up/improve stability of code and infrastructure

[jstet]

As there are currently mostly @KonradUdoHannes (on a volunteer basis) , @friep (who is understandably very busy with other important things) and me (who works 6h a week) working on the website, the capacity to fix bugs and react to infrastructure failures is limited. Also, the codebase is getting more and more complex. Therefore I would like to invest some time into cleaning up and increasing the stability of the website and associated infrastructure (directus).
This includes:

Coding/Javascript related

1. Adding more unit and e2e tests: In the recent past, some bugs were introduced with changes to the code that could have been avoided with more tests. For example some svg icons were invisible suddenly because i accidentally deleted a line of code. But there is a limit to how much tests we can write and we cant cover everything.
2. Generally cleaning up the code:

• less duplicate code, for example in the serverside rendering
• uniform naming
• more comments?

3. extend/improve abstract explanation of how the website works/where to find things

Directus/ Infrastructure related

4. Static build should include all assets #505 : website wont display images when our directus instance is down.

5. Move the state of the IaC code (directus on vps with connected managed db) to some remote storage so I am not the only one able to change it.

6. Add simple observability to the directus instance (dashboard with basic metrics so we know whether it has enough resources/is stable). Maybe DO graphs are enough.

7. Add basic notifications in case directus is down. (send an email)

8. How do we handle updates of the directus software?

[KonradUdoHannes]

I agree. I think we should try to scope some specific stability/quality goals and then address them in sub-issues. Coordinated from here.

I think the scoping is important because as mentioned above one can always write more tests, increase quality and stability.

Possible ways to scope on the Coding/JS related refactoring

• Introduce a test coverage tool und require a certain amount of test coverage
• define our own naming guidelines (possibly other guidelines)

I think the Infrastructure part is already scoped pretty well an can be turned into sub-issues quite well.

[jstet]

Static build now includes all assets

[jstet]

7. is already implemented by using DO monitoring and sending notifications to a slack channel

[jstet]

We could implement testing with Storybook and add a documentation like this: https://www.wix-pages.com/wix-design-system-employees/

[jstet]

• Ill start simple by deleting unused code
  See https://github.com/CorrelAid/correlaid_website/tree/540-clean-upimprove-stability-of-code-and-infrastructure

[jstet]

• Naming enforced
• No console log enforced

[jstet]

Next task is to standardize and improve parsing of cms data.

The goal is to sep. data processing and type checking/completeness checking. For the latter, typescript would come in handy: https://www.typescriptlang.org/docs/handbook/interfaces.html

Problem: fields in directus are not camelcase

At the moment we declare data fields in three places: in the graphql query, the rendering functions and in the components.

We are going to use: https://github.com/jquense/yup

[jstet]

Furthermore, all function should be documented

[jstet]

I am going to merge the existing work and implement yup in a sep. branch

[jstet]

implement a better component structure (e.g. one folder for cards)

[jstet]

Add way more tests