You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 5, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 5, 2026. It is now read-only.
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.
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.
In my understanding, there's two distinct web apps in our roadmap currently:
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.
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.
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
@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
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:
@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.
@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.
Activity
shrugs commentedon Jan 22, 2025
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 commentedon Jan 22, 2025
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 commentedon Jan 22, 2025
@shrugs Good feedback, thanks.
In my understanding, there's two distinct web apps in our roadmap currently:
My current mental model is:
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 commentedon Jan 22, 2025
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 commentedon Jan 23, 2025
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:
@ponder/clientlibrary that allows querying indexer directly from any JS client while using the Dizzle ORM query API@ponder/clientneeds access toponder.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 packagerootPathtk-o commentedon Jan 27, 2025
Just wondering if we need a nextjs app for the ensnode.io.
What do we plan to do with this website?
lightwalker-eth commentedon Jan 27, 2025
@tk-o Great question. Key goals are:
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:
I shared a few other little ideas in Slack here: https://namehash.slack.com/archives/C086Z6FNBHN/p1737744205514089
Advice welcome 👍
lightwalker-eth commentedon Jan 27, 2025
@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 commentedon Jan 27, 2025
@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.
[-]Initial monorepo configuration[/-][+]move ensnode.io to monorepo (fka Initial monorepo configuration)[/+][-]move ensnode.io to monorepo (fka Initial monorepo configuration)[/-][+]move ensnode.io to monorepo[/+][-]move ensnode.io to monorepo[/-][+]Move www.ensnode.io to monorepo[/+]tk-o commentedon Feb 3, 2025
As a team, we decided to create an Astro Starlight based documentation website: