-
Notifications
You must be signed in to change notification settings - Fork 15
feat(monorepo): split indexer into apps and packages #68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Use abstraction to detach the subgraphGraphQL factory function from ponder
Use abstraction to detach the helpers.ts functions from ponder
Use abstraction to detach the ids.ts functions from ponder
Move the indexer source code into its dedicated place in the monorepo workspace
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Exciting to see this taking shape 👍 A few very small comments.
Simplify common packages version management
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Hey nice updates 👍 Shared a few more small ideas.
|
@shrugs, do you think, for this PR, that we should also work towards:
? I wanted to export I've found an explanation to that drizzle problem, but didn't yet figure how to solve it. Not sure how to progress about that. What do you think? |
shrugs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great work on this with the catalog definitions and the readmes and whatnot. some minor stuff i've noted from afar, but i'll check this out and start running it now
| @@ -0,0 +1,5 @@ | |||
| export const uniq = <T>(arr: T[]): T[] => [...new Set(arr)]; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this file can/should live in the indexer, it doesn't need to be shared. and the file name helpers really only makes sense in that context.
| // produces `blocknumber-logIndex` or `blocknumber-logindex-transferindex` | ||
| export const makeEventId = (event: Event, transferIndex?: number) => | ||
| [event.block.number.toString(), event.log.logIndex.toString(), transferIndex?.toString()] | ||
| export const makeEventId = (blockNumber: bigint, logIndex: number, transferIndex?: number) => |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i would prefer this file live in the indexer as well — i'm not sure we'll need to generate any of these ids outside of that context, and these ids are indexer-specific. there was a mention of maybe resolverId being used outside, but let's move all of these back to indexer for now, and only extract that one iff we actually need to do so.
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Nice updates 👍 Shared a few more ideas with feedback 😄
shrugs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may not need to include vite resolution in root package.json?
|
just noting for myself: i'd really like for env variable management to be exclusively at the root — can likely configure this with dotenv executing the script before running ponder if necessary |
|
also note to self: i worry this is too package-happy but the plugin framework can be extracted into its own package, initially private but publishable in the future |
|
Thanks you so much for your support here, @shrugs 🚀 |
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Hey super updates! 😄 Shared a few more small ideas with feedback. I think we're very close now!
apps/ensnode/README.md
Outdated
| - (possible) continued backwards compatibility with subgraph | ||
| - support indexing subset of data, i.e. only domains under parent node | ||
|
|
||
| ## next up |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Hey if I remember correctly I saw an earlier request from Matt to remove the ideas in this "next up" section and transfer them into GitHub issues. I think it's best we action that outside of this PR and have Matt take the lead on that transition of ideas, since he's the original author of these and he'll understand them best.
Let's revert this change so that we retain these ideas as they are for now.
Sorry for the back and forth on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted. FYI @shrugs
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Great updates! Just one more set of open questions based on your proposed CI updates.
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tk-o Super updates. Replied to your question and small comments 👍
lightwalker-eth
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
if ensnode-utils is going to be internal, let's add do we need the we should standardize on whether we're going to org-prefix package names or not. i've done so for shared-configs (it's package name is |
shrugs
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ready to merge, up to you on package name stuff, or whether to tackle separately. well done!
| RPC_URL_59144: https://linea.drpc.org | ||
| RUNTIME_CHECK_TIMEOUT_SECONDS: 10 | ||
| run: | | ||
| pnpm dev -vv & |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
start command here, yeah?
|
@shrugs Agreed on your feedback about org prefixing all our package names here 👍 Let's keep all our packages private for now, including |
|
if ensnode-utils is intended to be public in the future, that's reasonable and i agree - i had understood it was meant to stay private forever |
|
I'm going to update the Custom Start Command on Railway for the indexing service. From: to: |
|
@tk-o Sounds good! Thanks! |
Related to #52
Goals
@ponder/clientfeatureponder plugins to be split into packagesrootDirrootDiris a single location, hence, having plugins in separate directories won't workponder-shemapackage to hostponder.schema.tsensnode-commonpackage to host all primitives that can be used outside of ponder app context, for example, on the client sideappsto host all runnable modulesensnodeponder app will be the first module hereensnodeapp will import ponder schema & config from theponder-bootstrappackagerootDir— having ponder plugins in play, also place in therootDir, prevents extractingponder.config.ts&ponder.schema.tsinto a separate package