3 min read
Graphql API Url: https://progressium-api-g44qf6ssma-uc.a.run.app/api
Local development: http://localhost:4000/api
Checkout the latest release
Progressium API is a tool to control simple startup phases. API doesn't include support for editing default phases. Phases are linked to each other, so that some rules are applied.
Rules
- You can add tasks to any phase in any state.
- Only tasks those are in an unlocked phase can be checked as completed.
- When all tasks are checked as completed, next phase is unlocked.
- When a task from previous phases checked as uncompleted, next phases get locked.
- When a task from previous phase checked as completed when there are next phases completed, next phases get unclocked until the next uncompleted phase. There is a traverse in the code.
Features
- List phases
- Add tasks for each phases
- Do/Undo tasks
You can import api collection -> api-collection.json
This is a dummy application that applies scalable approaches to regular problems.
Clean Architecture
The point with this approach is to keep the dependency flow as their importance and dynamism. If you carefully read the code, you will realize that;
- Domain never references other components. It is as clean as unit, easily testable.
- Domain rules stays in domain. Domain is the most crucial part of the application, anything can change and might need to be scaled but domain should be protected from those changes not to harm the business. This is why domain is designed to be smart classes, it doesn't include simple interfaces.
- Around the domain, there is application where we handle business operations. This part is pretty changable, new architectures and approches will always be there. Different domain needs will occur in time, this part will adapt any changes and needs.
- Around the application, there is persistence where we implement persistent needs. Since it is a small demo application, I put infrastructural needs also in persistence.
- Around the application, there is also infrastructure where we implement external libraries such as cache, logging, event bus etc. It is very important to abstract those in application component to prevent any future problem when they needed to be replaced with other libraries.
Simply; it is to control dependency flow, to keep components independent, to make components easily scalable and testable.
See here as well for more information.
Domain Driven Design
Shortly, make domain smart and ubiquiotus language! Domain should be talking to you. Yes, code can speak the same language as you do. It requires a different way of thinking to implement scalable DDD, so this is a danger zone!
See here as well for more information.
Event Driven Design
It is very common among decoupled services and it also perfectly fits to DDD. The business needs of my demo required me to use an in memory event design.
See here as well for more information.
Functional Programming
Clean, easily testable and stateless. No more words needed :)
Unit, Integration and E2E Testing
GraphQL
Workflows & Deployment
Build: It builds with webpack to bundle my code.
Linter: It lints with eslint to make sure a clean code.
Tests: It tests with jest.
Deploy: It containerizes with docker. It creates an image and push to google container registry. Then triggers google cloud run to deploy the container.