Independence from egghead-rails

[garrettdimon]

As time goes on and we're increasingly building apps and tooling with TypeScript and the egghead-rails codebase gets a little long-in-the-tooth, it looks like moving egghead-next towards being a standalone application is the right move.

Ultimately, that will mean one-by-one replacing HTTP requests to app.egghead.io with alternative approaches. As we're using Prisma in the monorepo, that's likely the solution for most of the requests. As I'm started exploring and thinking through what this process would like like, a handful of thoughts and questions have popped up. (For context, @jbranchaud did a spike of using Prisma in egghead-next a while back that provides some early insights.)

There are certainly other large topics we'll need to address, but adding read-only database access is the first baby step, so it's worth focusing purely on database considerations for now.

---

1. Legacy DB vs. New DB Schema

The most efficient way to begin migrating logic from egghead-rails is to begin using Prisma to work directly with the current Postgres database. Would we want this to be the long-term solution or merely a stepping stone to also shifting to a more curated and focused schema? (Keeping in mind that the egghead-rails DB would be the key remaining thing tying us to Heroku.)

If the latter, and we expect to generate multiple clients (one for the current database and one for the newer schema), then we'd likely want to have the legacy DB client use non-default Prisma settings so the long-term client could go with the flow and use the default settings and schema locations.

Another benefit to that latter might be that we'd be more alright using prisma db pull and making the minimum changes to ensure the schema works. A test run generating the schema found ~15 issues in a couple of categories that would need to be addressed. One of those is that join tables would need unique IDs. So we'd likely want to write migrations in Rails to make updates to the schema to reduce the friction of using Prisma.

2. New Database Type?

Would we want to use Postgres for the new database as well, or would it make more sense to go with Planetscale like we are on other projects? If we did go with Planetscale, while the Postgres to MySQL transition introduce too much awkwardness?

3. Migrations/Schema Changes

Near-term, we'd want to ensure any database migrations still happened through Rails. Long-term, we'd have to begin using Prisma migrations at some point—or schema changes if we use a new database on Planetscale.

4. Reads & Writes

Initially, we could extricate a significant amount of logic by focusing purely on reads. Once we need to migrate logic that writes to the database, things become a little more complex. With a two-database solution, we could have some transitional adapters that read from the legacy database and make the updates in the newer database.

5. Data cleanup

We have some data/logic in egghead-rails that handles edge cases around subscription management. Before migrating any of that logic, we'd likely want to address the edge cases by updating the data rather than migrating the logic handling those edge cases. With a dual-database setup with the legacy and a new database, this could potentially be handled in an adapter that migrated the relevant data.

Similarly, if there's any remaining content we can migrate from the Postgres database into Sanity, that could help make the transition a little smoother in some cases.

6. Latency/Performance

This point is likely moot since we're already making http requests from Vercel to Heroku and then waiting for Heroku to make DB calls, but it's worth pointing out that the database access will no longer be happening on the same network and making sure we're comfortable with the performance aspects.

---

What else am I forgetting or overlooking?