Move www.ensnode.io to monorepo

[lightwalker-eth]

Key goals include:

• Transition to monorepo structure
  • feat(monorepo): split indexer into apps and packages #68
• Move the Next.js app for the ENSNode.io homepage out of NameKit into the ENSNode monorepo.

Here are some resources that might be helpful:

1. Ponder's example monorepo configuration
2. Review the NameKit monorepo configuration:https://github.com/namehash/namekit

Key subtasks include:

1. Update Railway config (for Ponder app builds)
2. Update Vercel config (for Next.js app builds of the ensnode.io homepage)

[shrugs]

Will there be any shared code between the website and ensnode project? If not i'm not a huge fan of the monorepo, since it adds complexity (deploys, merge-rules, etc) for very little organizational gain. Once the ensnode project goes multi-service in v2, though, a pnmp workspace makes sense, as it will likely share code amongst the various services.

If we just make the website it's own repo, configuring stuff like railway/vercel/etc becomes strictly happy-path, and we'll run into fewer of the obstacles that show up with monorepo deployments.

[shrugs]

Ah, now that i say that, it does seem like the website might share code in the future, to power the dashboard, i see. in that case a monorepo could make sense — we'll just want to make sure things are configured correctly as we set it up.

[lightwalker-eth]

@shrugs Good feedback, thanks.

In my understanding, there's two distinct web apps in our roadmap currently:

1. A "live dashboard" showing metrics and utilities for monitoring the status of an ENSNode instance. More details in the following Slack thread. I'll need more time to transition the ideas there into a task here in GitHub: https://namehash.slack.com/archives/C086Z6FNBHN/p1737206149803769. In theory each instance of ENSNode might run this. Therefore it might be accessible through domains such as https://alpha.ensnode.io.
2. A more general "marketing" landing page for the ENSNode project that lives at the https://ensnode.io domain. I'm also interested for this to become a home for our documentation so that we have a more pretty place to put it. I don't like the low visibility / UX or DX for our current wiki at https://github.com/namehash/ensnode/wiki. We might implement this using a framework such as https://nextra.site/ but also totally open to other ideas. This would also replace the Next.js app that's currently serving up the ensnode.io homepage that lives inside the NameKit monorepo currently (not a logical place for it, but was a super quick action we took last week just to ship something): https://github.com/namehash/namekit/tree/main/apps/ensnode.io

My current mental model is:

• (1) will live directly inside the Ponder app (rather than being a separate web app) to support the goal of simplifying the deployment narrative for others running ENSNode.
• (2) will be a different app (from the Ponder app) inside the ENSNode monorepo.

Very open to other ideas. Just sharing my own current mental model. Critiques always welcome 👍

@tk-o FYI on all of the above. Also appreciate your advice on everything. Cheers.

[shrugs]

if 1) since it's more of an every-ensnode website that's talking to ponder that's definitely a case for a pnpm workspace ala the ponder monorepo example.

for 2) if we're already going monorepo for 1) then yeah it makes sense to huck it in there as well

[tk-o]

I've started looking into which parts of our ponder app might be imported by other apps we plan to build.

Here is my understanding so far:

• we want to build a website with dashboard, so we'll need to query the indexer
  • Ponder v0.9 will include @ponder/client library that allows querying indexer directly from any JS client while using the Dizzle ORM query API
  • @ponder/client needs access to ponder.schema.ts, so the schema file is a shared dependency, however, not yet sure if we can have it extracted from the ponder app into its own package
• we wanted to make ponder plugins as packages, but it will not work, as ponder app expects all handlers to be present under a single rootPath
• we wanted to make the subgraph grqphql middleware an opt-in package to encapsulate all of its dependencies separately

[tk-o]

Just wondering if we need a nextjs app for the ensnode.io.

What do we plan to do with this website?

[lightwalker-eth]

@tk-o Great question. Key goals are:

1. Communicate the value proposition of ENSNode (ex: a "marketing landing page").
2. Serve as the home for the documentation of ENSNode (including all apps and packages in our monorepo).
   1. This includes fully replacing the existing Wiki: https://github.com/namehash/ensnode/wiki I don't like the UX or the DX of the GitHub Wiki.

Based on these goals, I don't believe we want to build a totally custom Next.js app for these purposes. Instead I think it would probably be best to use a "higher-level" documentation site framework such as one of the following:

1. https://github.com/withastro/starlight
2. https://nextra.site/

I shared a few other little ideas in Slack here: https://namehash.slack.com/archives/C086Z6FNBHN/p1737744205514089

Advice welcome 👍

[lightwalker-eth]

@tk-o One more recommendation: For the first version of this new ensnode.io website that we add in the monorepo, suggest we keep it extremely minimal (ex: just replacing the existing ensnode.io website).

We should make separate future issues / PRs for enhancing it.

The goal of this issue is just for the site to live in our monorepo.

[lightwalker-eth]

@tk-o Also, for this goal, I'm thinking we would host the site using Vercel. We already have a Vercel account and it should be easy to setup for our goals here.