Starchart: 1.0.0 Release

Working Toward First Release

Finally, the Starchart project has reached 1.0.0 release!

After the handwork of the team, we managed to have it running on staging and then production. We encountered issues, such as incorrect AWS credential in production, having to deal with certificate request duplication (See PR), and splitting Docker image deployment between staging and production (See PR), but it's working now!

In the previous week, I was working on code for migration for both staging and production, as mentioned in the previous blog post.

This week, I made a PR to remove all mentions of deactivated user field, as well as related functions: deactivateUserByUsername, and isUserDeactivated.
This is because we decided we no longer need it and would simply delete user, which would cascade the delete to all DNS records and certificates belonged to the user, due to how it's set up in Prisma schema. Then, the reconciler code would sync the changes with AWS Route 53 we use.
The PR is important because it changes schema, and the migration code from my previous work successfully perform migration to update the databases in staging and production.

Reflection: The Work

I'm glad I had this experience and know that this is something I can do. It was great to be part of a team and build a project from the ground up, which is very valuable to me as a developer. When it started, I choose to be the expert on the database side of the project, because I'm interested in database and the management. While the actual maintenance is handled by Seneca ITS, I still got to work with database and have the experience of being the go-to person for that area on the team.

I got to learn new technologies, such as Prisma, and use them for the project. It's nice to experience having to pick up new technologies to work on a project, which I imagine won't be the last time I do it.

The people on the team are great. They are open and helpful. When you step out of of specialty on a project, it can be a bi intimidating to pick up what has been done in other areas of the project, and having someone who's willing to walk you through their area and answer your question is very valuable for the process and learning. I'm thankful for all the teammates who gave me a hand.

Reflection: Prisma

Prisma is the chosen tool for bridging the rest of the code and the database, and it has been pretty pleasant to use. Partially due to use of TypeScript, it's very robust in catching mistakes even before you have to run tests for your code. It also simplifies the work of issuing SQL statements interact with database. For example, instead of writing a lot of SQL statements to create a table, you can just code a visual layout with far less things, like:

model DnsRecord {
  id           Int             @id @default(autoincrement())
  username     String
  subdomain    String
  type         DnsRecordType
  value        String
  description  String?
  course       String?
  ports        String?
  challengeId  Int?
  createdAt    DateTime        @default(now())
  updatedAt    DateTime        @updatedAt
  expiresAt    DateTime
  lastNotified DateTime?
  challenge    Challenge?      @relation(fields: [challengeId], references: [id], onDelete: Cascade)
  user         User            @relation(fields: [username], references: [username], onDelete: Cascade)
}

I wrote about how this work in another blog post when working on the first iteration of this schema.
It's easy to write and see visually. The varies Prisma API calls also lets you interact with database from rest of your code in a project.