TaskRatchet is a project I built back in 2020 and have continued to maintain and develop since, as time allowed. It’s a task management app that allows you to stake real money on completing each task by its associated deadline.
Recently I drafted this list of technical changes I plan to make to TaskRatchet:
- Remove Astro, switch back to just React
- Use Clerk for auth instead of db auth and firebase auth
- Deploy to Cloudflare instead of Render.com
- Spin down API v1
- Set up API v2 to publish an OpenAPI spec
- Switch from one list of tasks to two or three (e.g. Next and Archive)
- Set up Honeycomb on the front-end
I thought I’d give a bit more context for each here.
React Over Astro
A while back I added Astro to the web app as a way to slowly transition away from React. My reasoning was that React introduced some unfortunate performance issues, and there were other front-end libraries I now prefer over React, such as Vue or Svelte. Astro would allow multiple front-end libraries to co-exist during a transition.
I now think this was a mistake.
- The main performance issues were due to having two-way infinite scroll in the main tasks list, and I separately want to get rid of that. (Already have partially.) So I think all the performance improvements I need can be made without leaving React.
- Even though I might like other view libraries better, I have the most experience in React.
- AI coding tools are really good at working in React.
- React is better supported by other things I may want to use than are Vue or Svelte.
None of this is to say anything negative about Astro. I love Astro. But it wasn’t a good direction to take in this case.
Use Clerk for Auth
This one’s a bit painful. Currently under the hood I have two authentication strategies which are operating in parallel: our own home-spun database-powered auth, and Firebase Auth. My tentative existing plan was to move everything to Firebase Auth.
However now I’ve used Clerk auth on several other side projects and it seems really great. It has React components for login, registration, forgot password flows, etc, so it will allow me to simplify the codebase while improving the user experience around authentication.
Of course, that means transitioning two systems to a third new system, which is the painful part.
Switch from Render.com to Cloudflare
Currently TaskRatchet is deployed to Render.com. Render.com has a fantastic developer experience, but it isn’t cheap for someone like me who creates a lot of little projects. So I’m working on learning Cloudflare and moving all my projects to it for hosting and compute. It makes sense for TaskRatchet to be a part of that.
Spin down API v1
Currently there are two versions of TaskRatchet’s API, and the web app uses both. I’ve been working intermittently on getting to the place where TaskRatchet only uses v2. Once that happens, I can spin down v1 and simplify our backend.
Publish an OpenAPI spec
That’s OpenAPI, not OpenAI. Having an OpenAPI spec will allow for us to generate public API documentation from our code rather than having keeping the API documented be a separate task from building the API. Also it will allow us and users (if they wish) to use the spec to generate clients to ease use of the API.
Split the Main Task List
Currently all of a user’s tasks are shown in a single task, including completed and past-due tasks. In the future I hope to split this into multiple lists, both to make the user experience more focused on a user’s relevant tasks and to improve the performance of the web app. Tentatively this means one list for tasks that are due within the last 24 hours and into the future, and a second list for everything else.
Add Honeycomb on the Front End
I already use Honeycomb for back-end instrumentation to allow me to see errors and try to track down the causes of problems. I’d like to add Honeycomb to the front-end, too, to increase my visibility into issues which may span the whole stack.