Last week, I ended up going in a slightly different direction than I initially planned, but I would say the outcome was positive overall.
I had planned to implement new post mutation features, but quickly realized that it would make more sense to first address an issue with the preexisting post repository and service. Basically, the repository was handling too many business rules, while the service was almost trivially wrapping the repository. By refactoring to have the service orchestrate transactions while the repository performs simpler tasks, I was able to achieve better separation of concerns and make it easier to add more functionality moving forward. I also made a few other minor improvements to the way the app state, config, and database connection were being initialized at startup.
Since I created a mock post repository for the post service tests, this refactor allowed me to write tests for all of the post creation logic, including rules related to archived and deleted posts, even though the post mutation features are not implemented yet. This reduced the pressure to implement these features, since I no longer have to worry about certain parts of my existing logic being untested.
Accordingly, I decided to change direction a bit moving forward. While I would love to keep implementing more features across the stack, I think it would be more beneficial for me to spend my time pushing forward and encountering more unfamiliar topics, circling back around to features at the end if time allows. Namely, I want to get more into deployment and documentation concerns in the coming weeks.
This week, I plan to tackle a few final issues before feeling comfortable with an initial deployment. The main area I want to address relates to database migrations. I’ve been using Rust’s SQLx crate (library) and CLI tool, and while most core functionality is quite ergonomic, I’d like to explore augmenting this with a host language agnostic SQL migration tool to maintain both a single source of truth schema and incremental migrations in a more structured way. I’d also like to automate the creation of some seed data. There are also a few other more minor points I’d like to touch briefly, such as dependencies and logging.
The main issue I expect to face this week is the unpredictability of exploring new tools. I’ve briefly looked into what I’m hoping for, and it seems like there are some good options, but it’s always possible that things don’t work out as expected when it comes to actual implementation in a specific project. However, the functionality I hope to add is not crucial, so even in the unlikely event that nothing is quite right, I will still be able to successfully move on to the next steps of the project.
I would say that I continued to improve upon my process last week. I had previously just been using pull requests, but I’ve now started a GitHub Project (kanban board) and am tracking issues in it as well. While I haven’t completely built it out like one would in a large team project, I’m a solid few steps closer, and I’m already feeling more fluent with this workflow.