-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
A plugin architecture for self-hosted shields instances #9787
Comments
Asking more for the sake of spurring the discussion as opposed to leaning one way or the other, but what are the reasons why the Custom Endpoint model couldn't suffice? |
Yeah its an entirely valid question. If you want to use that approach, it requires you to run some kind of single endpoint microservice to sit between your shields install and the service you want it to talk to. A plugin would allow your shields instance to talk directly to that service via its API. Maybe that's not enough of a reason though. |
I think the other point of consideration would be the simplicity factor relative to config and authorization (much of which would have to be reimplemented within the Custom Endpoint model) |
None come to mind right now. |
Another though on this: As well as things like That is quite a big downside. |
📋 Description
This doesn't come up all the time, but occasionally someone pops up and asks us to add a badge which would only make sense for a self-hosted install.
We usually say no to these requests. If there is no public instance of the service, it is difficult for us to test that this code works (either manually or via integration tests), making it hard to support, maintain or refactor.
That said, this has come up a non-zero number of times and the requests are not completely invalid. For some subset of self-hosting users, these badges could be useful.
So here's an idea: We provide some kind of plugin hook or extension point that allows self-hosting users to write and maintain a custom service. This would allow this category of users to self-serve their own feature requests without them having to maintain a fork or us having to take on the maintenance of code that would be zero use to the users of shields.io.
The thing that has made me think of this recently is Artifactory. I know this issue has come up before, but I can't think of any other examples to hand. So my first question is: Can anyone remember any other cases? It would be useful to collect up a few examples to help think about this. Also it would be useful to get some idea of whether there are enough use-cases to warrant solving the challenges this presents us with.
Here's some initial thoughts about what a plugin system might look like:
local-services
(for the sake of argument)..gitkeep
in it.services
dir, the loader also searches thelocal-services
dir./local
to namespace them. That means there won't be clashes with other URLs we add to core in future.That sounds kinda reasonable-ish, but it does bring up a number of problems, tradeoffs and questions:
shieldsio/shields
and copying some extra files into it. Another might be to mountlocal-services
as a volume and give it some files that way? Does anyone know of any examples of other projects that have this kind of setup? It would be interesting to look at some examples.BaseJsonService
at the moment, its a bit of a pain but fundamentally we only have to account for that in our own codebase. Once you have self hosting users extending that class, a non-backwards compatible change has wider implications.privateConfigSchema
. Of course, that wouldn't stop someone directly callingprocess.env.MYVAR
in the service code, but I feel like we could do better. What other obvious important things does my strawman implementation overlook?The text was updated successfully, but these errors were encountered: