Posts

Posted on

Costs to Expect API, v1.24 -> v2.00

Before I start developing the Costs to Expect app, I need to enhance the Costs to Expect API. Two significant features are going to be in the next version of the API, permitted users and multiple items types.

Permitted users

The Costs to Expect API supports authenticated users; however, the assumption is all authenticated users have the same data access. This system works at the moment because there are only two users; this works at the moment as there are only two users. The app needs to support multiple users with their own private data, so I’m going through the app and adding the necessary user links.

Multiple item types

The `item` table is set up for child expenses; that was all I needed for the initial development of the API. Looking forward, the API needs to support more complex item types. In the next release, I’m going to add support for multiple items types with a long term goal being support for custom item types.

The item type will need to be selected when you create a resource type. If you are tracking expenses you will choose `expense item type`, for budgeting you would choose `budget expense type`, and for a list, you would select `list item type`.

Custom item types will be coming; at this time, I can’t confirm when. I need to develop the budgeting and forecasting system; after that, I will be able to give a rough timeline.

Version 2.00

The features above are significant, far more significant than any additions to the API since its release in 2018. I feel that these additions are enough to justify a v2.00 release. 

A bump in the major version means I’m not going to support upgrades from v1.24 to v2.00. Upgrading from v1 to v2, will be possible. To upgrade you will need to export and import your existing data into a new instance of the API. I suspect there will be a join/relationship table between `items` and their data. Until v2.00 of the API is out, I am unable to confirm the exact setup; it is still in development.

Custom item types are unlikely to be supported in the v2.00 branch, I suspect, they will be the notable feature for v3.00. Unlike the jump from v1 to v2, I can guarantee there will be an upgrade path from v2 to v3, the existence of the app and website (Costs to Expect service) will require it.

Posted on

Open Source Costs to Expect website

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.