I have decided to Open Source the Costs to Expect website.
I planned the website and the app for the service as a single app. Over time, I’ve concluded that although it may create additional work, it makes sense to separate the service app (app.costs-to-expect.com) from the public website (www.costs-to-expect.com).
Due to the limited requirements, the public website will never be an excellent showcase of the Costs to Expect service.
Until we decide I need help, I’m creating the Costs to Expect service by myself. Managing three apps is more involved than two; however, there are pluses to separating the products.
The public website is a minor part of the service; I have numerous features planned; however, they are much lower in priority than developing the app. I don’t want to be in a position whereby the website is restricting the development of the app.
For the next three to four months, I am moderately confident that I can develop the app and update the API without negatively affecting the website. I have request tests in place (thank you Postman) that will immediately notify me if I make any change to the API, which affects the website.
I added PATCH support to the Costs to Expect API in November. At the time I did the minimum, I only added PATCH support for items as that was the only data we needed to edit.
In March, I reviewed the PATCH code, making a few minor alterations.
It is now time to add PATCH support to the rest of the API. PATCH support will be added for resource types, resources, categories, subcategories and category assignments for items.
When I reviewed the PATCH code in March, I was looking at a single instance. This time I need to implement PATCH support across multiple routes; we will see how many changes I make in attempting to make the code DRY.
I have six tickets in my tracker, one for each route plus one additional chore for minor refactoring. If everything goes well, I should have a release ready in a few days, and I shouldn’t have created any extra refactoring chores.
I had planned to start developing the Costs to Expect service during the summer, as always, there be a slight delay. We decided that rather than steam ahead with new development, it made sense to deal with some of the technical debt.
Looking at the planner, I’ve got somewhere between two and four weeks of development to complete depending on how much debt we decide to pay back.
As it stands today, our release plans are as below;
Costs to Expect API
- v1.21.0 – Similar to the latest release, prep work and refactoring.
- v1.22.0 – PATCH support for categories, subcategories, resource types and resources.
- v1.23.0 – Summaries for categories, subcategories, resource types and resources
- v1.24.0 – Add support for permitted users.
Costs to Expect website
- v1.10.0 – General housekeeping and prep.
- v1.11.0 – Authentication
Phase two of the Costs to Expect service should begin after the above is complete. Phase two is a migration project; the functionality that exists in the web-app needs to be migrated to the website. My Wife will then be able to use the website full time, and the web-app can be taken offline.
Pagination is necessary; you don’t want your API/website/app to default to returning everything from the database, occasionally though you might want to fetch the entire collection.
On the Costs to Expect API, we have added a
collection parameter, if set to
true the pagination limits do not apply, and the entire collection is requestable.
There are a couple of caveats, the API defaults the parameter to
false, and we only allow the parameter for collections which will know will be limited in size.