Building Multi Component Features
Introduction to Multi-Component Features
In our previous lessons, we focused on building individual features like task comments. Those tasks were mostly local to our application — they involved a single database table and a few simple API rules. However, professional software often requires Multi-Component Features. These are features where the application must coordinate with external systems, such as cloud storage or third-party security tools.
The Task Attachments feature is a perfect example. To allow users to upload files to a task, we cannot simply save the file in a database. We need to:
- Store the actual file in a
cloud storage bucket(likeAmazon S3). - Save the
metadata(the file's name, size, and type) in ourdatabase. - Check the file for
virusesandsize limitsbefore saving it. - Provide a secure way for users to download it later.
Because there are so many moving parts, we use Phased Decomposition. Instead of trying to build everything at once, we group tasks into logical phases. This keeps the AI focused and ensures that the foundation of the system is solid before we build the complex API layers on top.
Architecture: Thinking Beyond the Database
When building multi-component systems, the API acts like a traffic controller. It doesn't do all the work itself; instead, it tells other components what to do. For Task Attachments, we need a Storage Strategy. We don't want to just dump every file into one big folder. We organize them so they are easy to find and manage.
| Component | Responsibility | Example |
|---|---|---|
Database | Stores information about the file. | File name: contract.pdf, Size: 2MB |
S3 Storage | Stores the actual file data. | A file located at /attachments/task-123/contract.pdf |
Validators | Checks if the file is safe and allowed. | Is this file larger than 5MB? |
One new concept we use here is a Presigned URL. Since we want our files to be private and secure, we don't give users a permanent link to the file. Instead, when a user asks to see an attachment, our system generates a special link that expires after 1 hour. This ensures that only authorized users can see the files.
Generating the Phased Technical Plan
Before writing any code, we must ask Codex to generate a Technical Plan. This plan maps out exactly how the 13 tasks will be distributed across 5 phases. We provide Codex with our specification.md and ask it to follow the patterns in our CODEX.md file.
You would prompt Codex like this:
"Given the approved specification for task attachments, generate a technical plan for TaskMaster. Reference CODEX.md for our coding patterns and existing database conventions."
Codex will then produce a plan divided into these phases:
- Phase 1: Foundation. Creating the
Attachmentdatabase model. - Phase 2: Storage Infrastructure. Building the
S3Clientto talk to the cloud. - Phase 3: Validation. Building services to check
file typesand scan forviruses. - Phase 4: API Integration. Creating the
endpointswhere the user actually uploads the file. - Phase 5: Testing. Running
end-to-end teststo make sure a file uploaded by a user actually reachesS3and thedatabasecorrectly.
The following diagram visualizes these phases and their dependencies:
Notice how Phase 2 and Phase 3 both depend only on Phase 1, meaning they can be developed in parallel. This is a key optimization opportunity in the workflow.
