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
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.
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.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The PDS packages makes many assumptions about it's execution environment:
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:
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.
The text was updated successfully, but these errors were encountered: