Devlog 8

I've had a very productive couple of days. Still no frontend yet, of course, but I've been refactoring the backend with a view to making frontend integration easier.

Today's work

Last night I focused mostly on splitting out my business logic from my handler logic to reduce complexity. The handlers are now responsible only for calling a service and retrieving either data or an error from it, then formatting and returning the result. The actual business logic is now in the services, which means I can extend and compose each handler much more easily.

One of the things this has allowed me to do is create a population script that simulates a call to the API and uses the proper logic accordingly. I've now got a mocked up script that creates a bunch of users and items with proper data, and the API now creates a default list and status for each user when they're registered. This should make testing a lot easier going forward.

Another benefit to this is that it made me completely rethink the "board" concept. I realised that, like with columns, I'm thinking too spatially. A "board" is actually just a list and its associated statuses, so rather than creating a board and assigning a list to it, instead the board is just a rendering of a list with its associated statuses representing columns. With this in mind, I can simply create a list_statuses table to map statuses to a list and then use these statuses as grouped columns. Much easier.

What's next?

The next thing I want to hammer out is restricting API access. Currently, I have authentication middleware that ensures a user's access token is valid and in date, but every user can query all resources. I'm going to add more middleware to verify the user's UUID and allow them to query only the items they own. Since items and reviews are public right now, this will only really apply to lists. It will be important in future, though.

Another thing I want to do is add a "superuser" field to the users table to mark a user as an admin. Admins can access admin endpoints that enable them to query and modify all data on the server, so it should be a case of just adding this value to the JWT claims and then having a piece of middleware that checks it for a "true" superuser status. I'll need to think about how to create an initial superuser and then promote/demote users. Something to think about.

Tell me what you think.