<aside> 📖
In the first stage of the API lifecycle, product managers and other stakeholders must define the operational, business, and security requirements for a single API or group of APIs. This requires them to agree on the API's intended use case—and identify the team members who will move it through each subsequent stage of the lifecycle. They should also create and configure a dedicated workspace where team members can collaborate, as well as a GitHub repository that is connected to a CI pipeline. These steps help stabilize the rest of the API lifecycle and establish locations and tooling for stage-specific work.
Source: https://www.postman.com/api-platform/api-lifecycle/
</aside>
Business (Why/What value): The purpose of this project is to 1. share my experiences and 2. build my portfolio.
Operational (How well / performance): I predict there will be <20 views a month. The blog does no have to up 24/7 and downtime for maintenance will be acceptable. If something were to break, I’d be ok with being down for 24+ hours since I don’t expect for this project to be used very much. I’m not sure how much blog content I will have by the end of the year or how much will build up over the year.
Security (Protection/Control): Admin can create, edit, view, and archive(soft delete) posts. Public can read (Unauthorized users can ONLY view).
Me, I’m both the sole stakeholder and project manager of this project. I set the vision, direction, and culture as the project manager. I invest the resources including time and money as the stakeholder.
Since this is a personal project for the sake of learning, it does not target a specific business problem. While it may be a small scale project, I still plan on implementing best practices such as pagination and enforcing CORS policy to make it a habit.
Rather than going with FastAPI which would grant me more speed and freedom to choose various libraries, I went with using Django + DRF since it has battery included (models, ORM, and other things like serializers) and I’m already familiar with it.
For the future versions it would be nice-to-have authenticated users, a commenting system, and other neat things like caching. For my initial version (v1), it’s a mvp where I just want something that is functional. The idea is to have a minimal viable product I can have people use and recieve feedback. With that feedback, we can implement desired features in future implementation. This saves resources (like time) as it allows you to implemented things that people want and avoid implementing things people DO NOT want. Note: I’m the initial target audience.
Since I’m developing in VSCode, I will be using a vscode workspace. I decided to use uv as my package manager and project manager. While I kept using a familiar backend framework (Django), I want to explore new tools. This allows me to try new technology while also keep the project complexity and learning curve low. I do realize the uv is new which could be seen as risky, but I am ok with taking the risk in this small project.