Category: Costs to Expect

Posted on

Side project of a side project

I’ve been working away building the Costs to Expect Service for a while and we are starting to make some real progress, before I started work on the next app for the service I wanted to test a couple of small ideas, enter my Yahtzee game scorer.

I released v1.00.0 of the scorer on the 3rd of August, the initial usable version was released on the 21st July. I worked on it for an hour here and there and quite quickly got it to a point where I deemed it featured enough to get a v1 label, it isn’t done but when is anything?

Building the scorer was freeing, I quickly tested some ideas and designs without having to worry about conforming to the design on the main Costs to Expect App. I discovered a couple of bugs within the API and also created new routes on the API to deal with requirements unique to the Yahtzee app, I suspect if I had ‘added’ the scorer to the existing App I wouldn’t have come up with the same design.

Looking at the API from a different perspective has been worthwhile, it forced us to rethink, rather than have a monolith App that is capable of everything, we decided to break everything up. The API is the core of the service and we are now going to have smaller focused Apps that can more easily be designed for there intended purpose.

The current App is going to be slimmed down to expenses only, a budgeting app is in the works and Pro versions of both will come along some time next year.

There are going to be more side projects of side projects, we have a few in the works. They have to take a back-seat for now as I need to get on with building the Budgeting app and I’ve a freelance project or two coming up that will steal some of my focus.

Posted on

How we expose Open Source REST API usage within our app

The Costs to Expect App is not an Open Source product; we intend to create a viable service; for now, we are keeping our secret sauce secret.

The App is built upon the Costs to Expect API, the API is Open Source and technically, anything we can do with the API, you can too. We aren’t gatekeeping your data; you can access your data through our App with the UI/UX we are creating, or, you can use other tools to fetch the data directly from the API.

To this end, we expose all GET, HEAD and OPTIONS requests, we hide POST, PUT, and PATCH requests as you can’t review them after the fact without unnecessary data being cached.

At the bottom of every page within the App, there is a table showing the required API requests. The table shows the request URI, the request METHOD, the response time, as well as was the request asynchronous or did we fetch it from our cache.

I appreciate that to the majority of users this data is redundant, yes there will be a visibility toggle; however, for the minority of users that are interested, I think the extra effort will be appreciated.

API requests table for the Costs to Expect App