Quote.Vote RC2: Phase 7 Is Ready for Parallel Contributors

This week we announced Quote.Vote v2 RC2, another major milestone in the ongoing rebuild of our open-source platform.

For anyone new to the project, Quote.Vote is a text-first discussion platform built around a simple idea: instead of reacting only to an entire post, people can respond directly to the specific statements and passages inside it.

We open-sourced Quote.Vote last year, and since then a growing community of developers has been helping us rebuild the application on a modern technical foundation.

The goal of the v2 migration has never been to simply make the code newer. We want Quote.Vote to be easier to maintain, easier to test, easier for new developers to understand, and ultimately capable of being maintained by a community rather than depending on one person who knows every corner of the application.

RC2 is an important step toward that.

The frontend rebuild is now mature enough that our attention is increasingly shifting to the remaining backend migration. Over the last several weeks, our Lead Developer, Moti Rebuma, and I have reviewed the Phase 7 roadmap against the code that actually exists today, corrected outdated assumptions, mapped dependencies, and reorganized the remaining work into pieces that multiple developers can safely take on at the same time.

Moti has now completed his technical review, his final feedback has been incorporated into the GitHub issues, and the next phase is ready for assignment.

So what are we actually migrating?

Quote.Vote has been evolving over the course of years, and like many long-running applications, that means parts of the system were built using different generations of technology.

The v2 frontend is built around Next.js and TypeScript, but parts of the backend still use our older Mongoose/MongoDB data-access patterns.

We have already adopted Prisma as the direction for the modernized backend.

So one of the major remaining Phase 7 goals is straightforward to describe even if the implementation is not:

Move the remaining backend database access from Mongoose to Prisma without changing how Quote.Vote behaves for users.

During our review, we discovered that the migration was actually farther along than the old roadmap suggested, as much of the GraphQL resolver layer is already written in TypeScript.

Several roadmap items still described the work as though we needed to convert large parts of the backend from JavaScript to TypeScript. That is no longer the primary challenge.

The main persistence migration is now:

Mongoose → Prisma

That discovery allowed us to simplify the roadmap substantially.

We reorganized the migration around the product

Originally, query migrations and mutation migrations were tracked separately. That made sense conceptually but it made less sense when we thought deeply about the code.

Quote.Vote's GraphQL resolvers are generally organized around product domains, where the same files can contain several related operations. Asking one developer to migrate "queries" and another to migrate "mutations" could therefore send both developers into the same code.

Instead, the implementation work is now organized around the actual parts of Quote.Vote.

The new umbrella is:

#500 — Domain Resolver Prisma Migration

Under it, the migration has been divided into focused domains:

• #501 — Posts and Content
• #502 — Comments, Quotes, and Reactions
• #503 — Users and Authentication
• #504 — Messaging
• #505 — Presence and Typing
• #506 — Notifications and Activity
• #507 — Groups, Domains, and Collections
• #508 — Retire Roster
• #509 — Stripe utility data access
• #510 — Shared resolver utilities and remaining resolvers

This is more than an organizational preference.

It means a contributor can understand one coherent part of Quote.Vote, migrate that area, preserve its behavior, update its tests, and submit a PR without needing to understand the entire backend first.

That is exactly the kind of development model we want for the project.

Establish the common pattern first

Before several developers start migrating resolvers simultaneously, we also need everyone working from the same underlying pattern.

That is the purpose of:

#153 — Integrate Apollo Server with Typed Context

In plain language, this establishes a consistent way for the GraphQL backend to access shared application services — including Prisma.

Rather than individual developers inventing their own way of creating or accessing the Prisma Client, the application will establish one predictable, typed context that resolvers can use.

For developers, that context will preserve things such as:

• Prisma Client
• authenticated user information
• request and response access where necessary
• pub/sub
• request metadata
• existing shared runtime dependencies

The important architectural rule is that Prisma Client should have an application-level lifecycle rather than being independently created inside individual resolvers or once per request.

Once that pattern is established, the domain migrations have a common foundation.

What is ready now?

A substantial amount of Phase 7 is now marked Ready.

The domain migrations currently ready for assignment include:

• Posts and Content
• Comments, Quotes, and Reactions
• Users and Authentication
• Messaging
• Presence and Typing
• Notifications and Activity
• Retire Roster

We also have several important independent pieces ready.

#141 — Validate GraphQL Schema Generation

This verifies that the migrated backend can reliably construct and execute the GraphQL schema, including resolver bindings, custom scalars, introspection, queries, and mutations.

#147 — Restore Subscription Resolvers and WebSocket Runtime

Our audit showed that this is not simply a matter of translating an old subscription file into TypeScript.

The current backend needs the actual subscription/WebSocket runtime restored and integrated with the modern architecture.

#429 — Rename Group to Tag

This fixes some historical terminology.

What Quote.Vote calls a Tag in the current interface is still represented as Group in portions of the backend and GraphQL API.

Cleaning that up first prevents someone from spending time migrating backend terminology that we already know we want to replace.

Some work is intentionally blocked

Another improvement to the roadmap is that we are being much more explicit about what should not be assigned yet. This is just as helpful as identifying what is ready.

The Groups/Domains/Collections Prisma migration waits for the Group → Tag work.

The shared resolver utilities contain some of the heaviest remaining Mongoose usage, including reputation, scoring, Vote, and VoteLog logic. Those should move in coordination with the domains that rely on them.

Relationship resolvers should migrate after their corresponding parent domains become Prisma-backed.

And SolidConnection requires its own Prisma model and migration path before the associated Solid resolvers can leave Mongoose.

Our goal is to make safe parallel development possible.

The bigger change is the development model

This is the part of RC2 that I am probably most excited about.

A year ago, Quote.Vote becoming open source mostly meant that the repository was publicly available and people were welcome to contribute.

Today, something more substantial is starting to exist.

Developers are finding the project, taking issues, submitting pull requests, returning for additional work, identifying problems we missed, writing tests, reviewing implementations, and helping us understand the architecture better.

Moti has increasingly taken on technical leadership around architecture, code review, integration, and deployment.

Now other contributors can increasingly take ownership of clearly scoped implementation work.

My goal is becoming less about knowing how every piece of the application works and more about helping make sure the project has clear priorities, clear issues, and enough structure for other people to contribute successfully.

That is a much healthier place for an open-source project to be, so the roadmap itself aims to reflect that change.

A good issue should increasingly tell a developer:

Here is the problem.
Here is the relevant code.
Here is what must remain unchanged.
Here are the dependencies.
Here is how we know the migration is complete.

From there our mantra is to let developers build.

Want to take one?

If you have contributed to Quote.Vote before, this is an excellent time to jump back in.

If you are new to the project and comfortable with some combination of TypeScript, GraphQL, Apollo, Prisma, Node.js, or backend testing, there are now several bounded migration issues that should be much easier to approach than the old Phase 7 roadmap.

Take a look at the issues marked Ready, find something that matches the part of the stack you are interested in, and comment before beginning so we can coordinate assignments.

Start here

RC2 Beta:

https://beta.quote.vote

GitHub Repository:

https://github.com/QuoteVote/quotevote-next

Phase 7 Prisma Migration:

https://github.com/QuoteVote/quotevote-next/issues/500

There is still plenty of work between RC2 and the completion of the v2 migration. But we've reached an important point. I want to thank all of the contributors who helped us get here.