Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta Issue: improving development process #23

bintzandt opened this issue Oct 19, 2019 · 0 comments

Meta Issue: improving development process #23

bintzandt opened this issue Oct 19, 2019 · 0 comments


Copy link

@bintzandt bintzandt commented Oct 19, 2019


The goal of this issue is to track to progress of improving the development process. The things that I want to improve, the reasons why and the suggested improvements are listed below. When all parts are finished, developing for Hydrofiel should feel fun again and it should be much easier to get started and to make progress.


  1. The development environment is hard to set up. The process that a new developer has to undergo before he/she can actually start to develop is very complicated and not documented very well. This scares people of. Since I want to make sure that people can continue to develop the website even when I am gone, this is something that needs to be improved.
  2. Deploying new code has to be done manually. Currently, new code is manually deployed by me using FTP. This is annoying for other developers as well as for me. Ideally, it should be possible to deploy new code by pushing to the master branch. In order to achieve this, some sort of CI needs to be set up.
  3. There is no coherent coding style. This is a problem because it is not clear for new developers how code should look and might lead to an unclear structure as time continues.


  1. The set-up should be as easy as possible. Preferably: everything a new developer should have to do is clone the repository, run some kind of install / build command and run a command to serve the website. My idea is that we switch to a JavaScript based framework. This has the advantage that the set-up is very easy. One can simply run yarn install to install all dependencies (and installing yarn itself is also very simple). Then separate commands can be made for building and running the site.
    I would also like to separate front-end from back-end code. This has the advantage that it is very clear where new functionality should be added and increases the modularity between the code. This in turn improves the structure and makes it easier to add new code because it is clearer where it should belong.
    My proposal for tooling would be: NestJS ( as back-end framework with a frontend based on React ( in combination with some kind of Static Site Generator (SSG) for making the static pages. As SSG I would propose to use Gatsby (
  2. New code in the master branch should automatically be deployed to the live site. This can be done by setting up Github hooks / actions that automatically build and deploy the site when a new commit is made. It is easier to build this after we have switched frameworks because deploying JavaScript code is way easier than deploying PHP code. .env files with variables could be manually copied to the website because they do not need to be changed very often.
  3. After 1. and 2. are done, eslint ( can be configured to make sure that we have the same coding style everywhere. This is easy when both the front-end and back-end are written entirely in JavaScript.
  4. More documentation. Whatever we choose to do, we should write more documentation so that it will be easier for new people to join the project. This documentation should be divided in four parts, roughly following the proposals made in the following link:


This list can be edited to link to more specific issues / pull requests. Please add the link at the end of the description.

  • Port the back-end server to NestJS.
  • Port the front-end to React / Gatsby
  • Set-up CI
  • Set-up a generic codestyling for the front-end and back-end
  • Write more documentation!

I am open for any kind of feedback, including proposals for another toolchain. Please let me know what you think.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.