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

Architecture: Dependency consumption and event flow #1749

Open
gabek opened this issue Feb 27, 2022 · 1 comment
Open

Architecture: Dependency consumption and event flow #1749

gabek opened this issue Feb 27, 2022 · 1 comment
Assignees
Labels
documentation Improvements or additions to documentation enhancement New feature or request

Comments

@gabek
Copy link
Member

gabek commented Feb 27, 2022

Since Owncast was built one piece at a time, with no overarching design upfront, the architecture reflects that. This needs to be resolved.

Things should be split up into dependencies that are injected into packages, top down. For example, the datastore should be injected to the user package instead of the package requesting GetDatastore().

A DI framework such as Dingo or fx may add structure around this, but it's not required.

Things like chat, activitypub and webhooks need to be treated differently. For example, chat is both a package that is currently treated as a standalone service, but chat is also used seen as a dependency for other services to reflect events that occur within Owncast. I think a middle-man service, something like an eventhub could be an answer. Where the eventhub, and only the eventhub, has a reference to the chat server, and all packages can have a reference to the eventhub injected. The eventhub then can do things like fire off chat, activitypub, webhook and plugin events as needed, without the packages knowing the specifics about these destinations

But experimentation and the determination of what pieces go where need to be done. I'll probably want to diagram this before writing any code.

@gabek gabek added documentation Improvements or additions to documentation enhancement New feature or request labels Feb 27, 2022
@stale
Copy link

stale bot commented Apr 28, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this was a feature request that others have shown no interest in then it's likely to not get implemented due to lack of interest. If others also want to see this feature then now is the time to say something! Thank you for your contributions.

@stale stale bot added the stale label Apr 28, 2022
@gabek gabek added the backlog Ideas that might be cool and can be looked into later. label Apr 28, 2022
@stale stale bot removed the stale label Apr 28, 2022
@gabek gabek added this to the Backend cleanup and refactor milestone Mar 14, 2023
@gabek gabek removed the backlog Ideas that might be cool and can be looked into later. label Mar 14, 2023
@gabek gabek self-assigned this Jun 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant