Week 5 — Software and Everything
CI/CD?
Continuous Integration is an automation process for building and testing an application, triggered by a commit pushed within a repository. Continuous Integration is a stage where all developers’ code are integrated into one, in our main repository, PPL-C3, at Gitlab. In this stage, codes we commit are merged into a branch associated to a certain PBI, and tested to make sure that our code integrates well with the existing system. I have put the code snippet in my previous blog, and the main points are that our CI scripts do is that we run three tests: test_frontend and test_backend and test_microservice. All tests are executed everytime someone pushes to any branch in the repository.
After the three tests are passed, we move to the CD stage.
Continuous Deployment is a stage where after CI stage is passed, any changes in the application is automatically deployed to a server. This is why it’s called continuous deployment. We deploy, continuously, after changes are made. At Println, we activate our CD Pipeline to run to our Heroku server. Code snippet also put in my previous blog.
Heroku as PaaS, and Why It’s Better for Println
A month ago, we decided to serve our production app in DigitalOcean, an Infrastructure as a Service (IaaS) platform. Our DevOps engineers (re: Mamad & Gunawan) spent almost two days setting up the server, programming in Bash scripts, reliving their Sysprog memories. This setup is super complicated, because DigitalOcean provides the infrastructure of a server to us. Meaning, we have the freedom to choose our infrastructure (like our RAM, memory, OS, etc), but we need to set them up ourselves. Basically, it’s like we buy our own computer, but someone maintains the hardware for us. Powerful, for large apps, but takes too much time, especially for students like us.
On the other hand, Heroku provides a platform for us to develop, run, and manage our application, without having to set up the other things. Bam, I set up not just one, but TWO servers (front-end and back-end server), which only consists of setting up the buildpacks (we use Python and Node.js buildpacks), setting up database (using Postgres; the free version), and configure the environment variables, AND changed the CD script in less than two hours. Well, that was quick.
See below for comparison.
This is why, setting up Heroku is way much easier than DigitalOcean, and we’re glad we moved it back to Heroku.
Software Architecture
Legend:
- straight arrow : request flow
- dotted arrow : response flow
Tech stack:
- Frontend : React.js
- Backend : Django Rest Framework, with PostgreSQL as DB
- Microservice : Node.js
- Dropbox : to save user files
- RajaSMS : to send notification to user
What architecture are we using?
There are many architectural patterns in software development, such as monolithic (where one app handles all), client-server (server provides a resource, client requests it), and one of the most well-known today, also implemented in Println, is microservices architecture.
Microservices architecture is a software architecture based on Service-Oriented Architecture (SOA), which divides its software into several small loosely-coupled services. Each service is modular and only responsible for a certain task domain. Currently, we have only one microservice, which is the print job service. This service is responsible for handling print jobs coming, printing them to the printer attached to its computer, and updating the status of the job.
Our implementation of microservices architecture is not yet perfect, since our backend app is not yet separated into small services. This is because in our current stage of development, we have yet to see that separating the codes are worth the time, and our application is still small. However, in large application systems, such as Tokopedia, Traveloka, etc., applications are separated into several services with specialities, such as payment, account, bookings, etc.
Other than microservices architecture, Println also seems to implement client-server pattern, because resources in the user are accessed via front-end, requested to the back-end. Our implementation of REST APIs also supports this argument. REST API helps us to separate concerns on front-end and back-end, so that client and server can communicate with low coupling, which improves the maintainability of Println.
Seen from the other perspective, we can also see it as a layered pattern, where each service is a layer responsible for its task. Frontend is the UI layer, the backend and the microservice is the application layer, and the database and Dropbox is the persistence layer. (Thanks to Intan)
Why do we choose this?
- Low coupling: easier to maintain, no need to understand the whole part/code because each service has its own responsibilities, not highly dependent to each other
- High scalability: because of low coupling, each service can grow interdependently and be developed separately, without having to wait for each others’ services
https://towardsdatascience.com/10-common-software-architectural-patterns-in-a-nutshell-a0b47a1e9013
What Have I Done?
- IsNotBanned permission: only a not banned user can access all the resources of Println
- Manual QA Testing: automated testing is a good way to test if our codes work, but manual testing is also important. We need to make sure the APIs are understood well, the UI is responsive, and the code works under every circumstances.
- Backend Documentation: I made a documentation for PrintTransaction APIs, for other developers to understand the payload, response, etc of the PrintTransaction endpoint. The documentation is published on Postman.
- Dynamic Pricing: To allow admins to set up dynamic pricing, and to control it from their dashboard. Backend task.
