CorrelAid / correlaid_website

Source code for the CorrelAid website
https://correlaid.org
3 stars 0 forks source link

Clean up/improve stability of code and infrastructure #540

Open jstet opened 9 months ago

jstet commented 9 months ago

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. https://github.com/CorrelAid/correlaid_website/issues/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 commented 9 months ago

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

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

jstet commented 4 months ago

Static build now includes all assets

jstet commented 3 months ago
  1. is already implemented by using DO monitoring and sending notifications to a slack channel
jstet commented 2 months ago

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

jstet commented 2 months ago
jstet commented 2 months ago
jstet commented 2 months ago

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 commented 2 months ago

Furthermore, all function should be documented

jstet commented 2 months ago

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

jstet commented 2 months ago

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

jstet commented 1 month ago

Add way more tests