-
Notifications
You must be signed in to change notification settings - Fork 1
Design and Development Principles
Ihar Suvorau edited this page Jun 13, 2023
·
3 revisions
-
Automation
- Building (GitHub Actions), testing (GitHub Actions), and deploying (GitHub Actions + Ansible) should be automated.
- Configuring machines in ETAIS should be automated (Ansible).
-
Breadth-first and API-first development
- While working on a user story, it's better to take a user story that spans across multiple services, so we can get a better understanding of the system as a whole after the implementation. Taking one microservice and developing it in full might lead to rework when we start working on the other microservices.
- We should also try to design the API first, and then provide the simplest implementation possible. This will help us to understand the API better, and also to get feedback from the other developers. The implementation can be upgraded to a more complex and feature-rich one later.
-
Python coding conventions
- Use
blackfor formatting.
- Use
-
Performance
- We don't optimize for performance unless it's necessary. Performance matters in the algorithms, not in the microservices.
-
Service-based approach
- We choose the service-based approach to enforce the API-first development, ensure clear boundaries between different parts of the system, and to be able to throw away certain services and replace it with others without affecting the rest of the services.
-
Scalability
- We don't expect the application to be highly scalable and serve hundreds of users simultaneously. However, it's good if a service can run several jobs in parallel or concurrently.
-
Development
- We use JavaScript, TypeScript and
Reactfor the frontend, and Python for the backend. - We use
flaskorfastapiwithuvicornfor web servers. - OpenAPI specification is required for all the APIs. It would help to autogenerate client libraries (potentially, servers).
- Databases are internal to its services.
- Commit and push code daily. Don't develop in a separate branch for days without merging.
- We use JavaScript, TypeScript and
-
Licenses
- Any tool that we use should be free to use for commercial purposes.
-
Archive (ignore this, for history reasons only)
- Jonas' Notes
- Developer Notes
- System Design
-
Developer Notes
-
System Design
-
Policies