Wlth is a free budgeting and net worth tracker that I designed, built, and run at wlth.app. Users set monthly budgets by category, link bank accounts to import transactions automatically, set savings goals with target dates, and record monthly snapshots of their assets and liabilities. Accounts that can't be linked, like a house or a car, can be tracked manually so net worth stays complete.

The app is a Rails monolith using Hotwire for the front end and PostgreSQL for storage. Authentication is handled by Rodauth with optional two-factor auth. Background jobs on Solid Queue sync transactions from the bank aggregator whenever a user logs in with stale data, or on demand. The whole thing is containerized with Docker and deployed with Kamal to Oracle Cloud free-tier ARM instances, so hosting costs nothing.

The third-party bank aggregator the app relied on recently shut down, so account linking is currently unreliable while I sort out a replacement. Budgets, goals, and manual accounts still work. Linked accounts simply stop receiving new transactions until linking is restored.

I learned the importance of observability the hard way when I was tasked with debugging a major issue in an application that was not observable. The app was essentially not working at scale but there were no logs, metrics, traces, or errors to help me understand the problem. This was also a problem because the issue was not easily reproducible. This led me to learn more about Datadog and how to use it to make software observable.

The first thing to be done was to upgrade Datadog within the application. Datadog was technically running on the app but no useful information was logged and any logs that did show up were not tagged with any information. I upgraded Datadog to the latest version on the application and even got it running in my local environment in docker.

Next I normalized the logging format in the application to make the logs consistent and informative. Including standard key value pairs such as customer IDs, class names, and error messages allowed me to see how the app was behaving at every step in the request cycle. Adding tags to all of the traces also allowed me to quickly identify where an issue occurred.

Metrics are important here because collecting all of the logs that come through the app is expensive. By utilizing metrics we can see the number of requests and errors at any point in the request cycle without indexing all of the logs.

The last thing needed to make the app observable was to aggregate the logs and traces in a Datadog dashboard. I used a timeboard to visualize the sampled logs at every step in the request cycle and displayed alongside them the error rates and metrics created from those logs. This has proven to be very valuable in debugging and monitoring issues reported in the app. It has significantly reduced the time it takes to investigate and fix issues.

I led a project to create a drag and drop content editor inside of a single page React app. Users could use the app to select pre-built or custom themes to create content. Inside the editor users could drag and drop predefined blocks of various types. Block types include components such as plain text, two column, image, and button. The purpose is to allow customers to create beautiful content without writing HTML.

The app is written in React and uses Redux for state management. The drag and drop components were written using a library called dnd-kit. One difficulty we ran into in this project was rendering the drag and drop components on top of a content preview panel. This is where dnd-kit was helpful. It allowed us to render an overlay on top of an iframe. The iframe rendered the preview of the content while the overlay calculated the position of the components the user would drag into the content.

While this was a front-end heavy project, the app was built on top of an existing Ruby on Rails app. There was still plenty of backend work to coordinate with the actions taken on the front-end. I also optimized the amount of data that was loaded at any time to make page loads fast and only return the data necessary for the current view. The load time on some views were reduced from 10 seconds to under 1 second.