Conversation
dholms
reviewed
Feb 23, 2023
| .where('post_embed_external.postUri', 'in', postByUser) | ||
| .execute(), | ||
| this.db.db | ||
| .deleteFrom('duplicate_record') |
Collaborator
There was a problem hiding this comment.
as we focus on backlinks more, we may want to make duplicate_record a bit smarter
dholms
approved these changes
Feb 23, 2023
Collaborator
dholms
left a comment
dholms
left a comment
There was a problem hiding this comment.
sorry for the wait for review
this is all coming together quite nicely!
mloar
pushed a commit
to mloar/atproto
that referenced
this pull request
Nov 15, 2023
* Separate app.bsky methods out into app view * Fix websocket issue while splitting-out app view * Start organizing app-view tables out of pds * Move feed service, getTimeline, vote table into app-view * Move record processing/indexing logically out of pds and into app-view * Pull actor service functionality into app-view * Factor app-view user functionality out of pds, replace actor w/ account service * Tidy
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The goal here is to isolate app view functionality for the bsky application logically from the rest of the PDS, which is more focused on hosting. The app-view functionality lives inside
packages/pds/src/app-view/, where lots of files have been moved or adapted out ofpackages/pds/src/.Database layer
In the db layer the following tables have been separated into the app view, all related to indexing bsky records:
duplicate_record,assertion,profile,post,post_hierarchy,post_entity,post_embed_image,post_embed_external,vote,repost,follow.A few exceptions to the factoring:
voteis shared by thefeed.setVotemethod in the PDS for now. Therepo_rootandrecordtables are shared so that the app view can tell if a repo/record is moderated. Anddid_handleis used by both. There is also a little tangle withmutes, which logically lives under the PDS but is used in the app-view.Service layer
The actor service has been split into the PDS's account service and the app-view's actor service. The PDS inherits the
com.atprototerminology ("account"), where app-view has theapp.bskyterminology ("actor"). All actor view logic is isolated within the the app-view, though it is currently used in two places in the PDS:graph.getMutesandnotification.listmethods.The record service has been split into the PDS's record service and the app-view's indexing service. In short, all bsky-specific indexing logic from the record service (i.e. the plugin/processing system) has been split out into the app-view's indexing service.
In order to maintain a loose coupling between these two services, a
MessageDispatcherimplementingMessageQueuethat handles messages immediately (i.e. in the same transaction as thesend()) has been introduced. For example, when the user writes a record to their repo the PDS dispatches an "index_record" message. The app-view receives this message, performs any bsky-specific indexing, then may push some "create_notification" messages onto the message queue, which are picked-up by the PDS.The services for the app-view live under
services.appView. I see the service layer as sort of the midpoint of the architecture (between method handlers and the db model), so it's a nice place to have any coupling between app-view and PDS explicitly documented.Still a few things to untangle, but now there's some proper logical separation between the PDS and app-view, and the overlap between the two is documented here as well as with
@NOTEor@TODOs in the code.