feat: Enable external plugins to provide storage, publishing and auth mechanisms #1887
Conversation
now builds all the files loaded into project (from arbitrary source) rahter than zipping a folder on disk
use custom storage if one is specified
add sample web route plugin first tiny stab at publish -- TIME TO BRANCH
|
Great to see, @benbrown i was working on a LocalBotManager service which implements "publish\history\rollback", it's ready now, so i was trying to implement a IPublisher in composer to hook up. I saw you already have a publisher, I will take a look see how i integrate with this. Also left some comments based on my learning and investigation. |
|
|
||
| import pluginLoader from '../services/pluginLoader'; | ||
|
|
||
| export const PublishController = { |
There was a problem hiding this comment.
Probably we should consider make this a REST api managing "publishers" which means:
- Get /publishers, return a bunches of publisher plugins with ID, having this will enable the UI to list out all the publishers and their recent activities.
- POST /publishers/:pid/publish, publishing using one publisher
- POST /publishers/:pid/(rollback/history/status)
There was a problem hiding this comment.
100% agree, this is part of the work I've done already in another branch!
| ]).join(' ') | ||
| ); | ||
| } | ||
| pluginLoader.loadPluginsFromFolder(__dirname + '/../../../plugins', app).then(() => { |
There was a problem hiding this comment.
loadPluginsFromFolders is great. Can you support also loading from code, by that, i was facing such a scenario:
I was trying to create a HttpPublisherGenerator which takes a config (name, host, etc) and return a IPublisher, so that for different slot, i will register different Publisher hopefully like this
var httpPublishers: IPublisher = [
HttpPublisherGenerator(config1), // config 1 with product slot url
HttpPublisherGenerator(config2), // config 2 with testing slot url
]So that, i wouldn't create a new folder only for a different endpoint.
My hope is those publishers are loaded together with plugins in the folder, and surfaced out through the same publisher server api.
Does this make sense to you, and what's your view on this.
There was a problem hiding this comment.
Having seen your implementation, I don't 100% agree with this.
I think you would register ONE instance of the HttpPublisher, and then pass in the appropriate config, which is a bot-specific setting rather than a Composer-wide setting.
There was a problem hiding this comment.
Thanks, saw you comments there, i haven't thought about whether the publisher configuration is per-bot or per-composer, my gut feeling is making the config per bot would be more flexible, on the other hand making the configuration in composer will be easier to manage and a little clean. Let me mark that as a open question and think about that. cc
two chris @christopheranderson @cwhitten
One of my focus on prototype was trying to setup a structure that code-based publisher and config-based plugin (throw HttpPublisher) can work well together. So that, average users don't have to code to enable a plugin (i believe that's part of intention of your original design doc) and we still keep the possibility to let user code when user want to or have to, for features that can't achieve throw by configuring HttpPublisher, which meet @christopheranderson's point at that meeting.
Anyway, either way it's OK to me, and we need to make sure we surface the configuration out, become multiple plugins or multiple profiles (for one plugin).
|
I am now exploring what it will take to make the storage layer identity aware -- that is, passing in user information from the auth system all the way down to each storage read/write operation. |
|
Superceded by #2023 |
Description
This PR includes 3 interrelated bits:
Still To Do
Type of change
Please delete options that are not relevant.
Checklist
Screenshots
Please include screenshots or gifs if your PR include UX changes.