The Most Important Delete Button I’ve Ever Written (Yet)
By: Chance Swartz
Tags: Personal, Node, Knex, Lambda Project

Out with the old, in with the new

Coming into this codebase, my team and I barely knew each other, and we were even more unfamiliar with the code. I was assigned to the backend, meaning the bulk of my work was done in either Node.js or SQL. This meant I also worked with the data scientists, who seemed to operate in strange and mysterious ways, seemingly speaking a language I had never heard before. (It reminded me of how other people probably felt when I tried to talk to them about work.)

As it turned out, the entire database had been rewritten at least twice, leaving a lot of legacy code that didn’t properly return anything. One of my personal challenges was that neither the database (which I oversaw) nor the endpoints were unified, and there was code pointing to several database rewrites. I spent most of my time testing the endpoints written in Express.js using Postman, rewriting sections as needed (so that whenever a user wanted to send or retrieve information, they could), and updating the migration tables to reflect the changes.

I also used Knex to maintain the database, which allowed me to reset it or reseed it, then finally submitted my code for peer review to make sure that everything followed our format and best practices. For those moments where I wasn’t doing those things or in a meeting with the team or the stakeholder, I was reviewing pull requests, so that the team could push good code to the main branch.

The trouble with inheriting a code base is that you never really know what is in it until you start digging. As a team, we had to dig through three separate repositories of code (front end, back end, and data science), and we sure dug. Upon review, and further review, and further further review, we had discovered that there was certainly plenty of work — for everyone.

The trouble with inheriting a code base is that you never really know what is in it until you start digging. As a team, we had to dig through three separate repositories of code (front end, back end, and data science), and we sure dug. Upon review, and further review, and further further review, we had discovered that there was certainly plenty of work — for everyone.

The new relational database we came up with

The first challenge I had with this mature code base was getting a simple delete function to work. On our service tracker, there was a specific table for each service entry that was provided (since removed, as per discussion with stakeholder). The previous team had built out a delete button, and it looked like there was code for it to work, but nothing happened when the button was clicked. After partnering with a front end developer, it turned out that the endpoint code for the button was legacy, and that it hooked up to a database that no longer exists. My partner decided to freshen up the function on the front end while I went to fix the back end. I wrote out a simple delete function in the model.

The delete model we created for Service Entries

After that, I linked it to the router, replacing the old one.

Quick change to the router

Once done with that, I went into the database and updated a few migration tables that interfaced with the service entry table. It was as simple as verifying that they interacted with each other through a foreign key, and then changing the change management from “RESTRICTED”, to “CASCADE” (so that if a service entry was deleted, the relevant data would be deleted from other tables too).

One of the migration table changes

After that, all that was left was to have my code reviewed, accepted, pushed into the main branch, and then reset the developmental database (rolling it back, migrating it, and then seeding it, all with Knex). After that, it just works!