Skip to content
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

Proposal: Make @atproto/pds runtime and infrastructure agnostic #2822

Open
tom-sherman opened this issue Sep 19, 2024 · 0 comments
Open

Proposal: Make @atproto/pds runtime and infrastructure agnostic #2822

tom-sherman opened this issue Sep 19, 2024 · 0 comments

Comments

@tom-sherman
Copy link

tom-sherman commented Sep 19, 2024

Is your feature request related to a problem? Please describe.

The PDS packages makes many assumptions about it's execution environment:

  • Node.js runtime (eg. req/res) and standard library
  • Redis is available
  • A file system is available
  • TCP sockets are available

This makes it practically impossible to run this software in eg. Cloudflare Workers.

Describe the solution you'd like

The library already allows some things to be decided by the host environment such as config and secrets, my proposed solution would be to continue this trend via the same kind of patterns set out in eg. The browser oauth client package.

Things like Redis, blob store, and databases should be abstracted into generic storage interfaces that can be implemented in the host environment.

For sockets, a generic interface could be designed or we could use the whatwg WebSocket API as this has implementations built into (or installable into) most JS environments.

This would also offer a solution for the HTTP server: the web APIs offer a much more widely supporter surface.

An example API sketch:

new PDS({
  keyValueStore: { get: async () => ..., set: ... },
  blobStore: ...,
  socketFactory: { createSocket: () => ... }
})

Describe alternatives you've considered

Forking or reimplementing the PDS package to support this architecture. This is relatively feasible to do but I have concerns about being able to keep it up to date considering the rate of change in the PDS.

I feel like the PDS is starting to stabilise as a piece of infrastructure with fewer features being added, but still it would be worrying to always be playing catch-up.

It is worth considering other APIs other than this kind of dependency injection composition technique eg. Plugin architectures.

Additional context

Running the PDS in more places is I think a brilliant way to encourage the proliferation of PDS self hosters and providers. Even though Bluesky may not have a direct need for a "PDS framework" such a thing would be super valuable to the community.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant