-
Notifications
You must be signed in to change notification settings - Fork 30
Frontend plugin registration #77
Comments
Maybe check for clashes of |
|
🤫 |
Just wondering, are there examples of the sorts of plugins you mean? Things like the admin app and viewer? Or others as well? An alternative approach would be to make the server module just present the API, and maybe have another project (EasySpeckle? or something like that) which pulls in the server, admin app, viewer, and does whatever plugin magic is wanted. This would mean that things are more modular, reduces dependencies of the server, and gives more flexibility (e.g. you could run the server and frontend separately, behind reverse proxies or something, if you really wanted) |
Happy we're having this discussion! This is how we had it before, back in the pre-1.x days. The server was happily unaware of anything and just fronting the api. There was server.speckle.works and app.speckle.works or viewer.speckle.works, don't remember. To get them all running together nicely, there was a bit of a hassle: separate subdomain optional, plus nginx proxying stuff, plus an extra config step in the static frontend to point it to the right api - and yes, i would stay away (for now) from frontend apps that can connect to multiple servers. For now. Other plugins that extend the api with compute stuff might go in there as well, but it's too early to say how (ie, stuff that calls an external api to do work). The move towards serving them from within the server itself was in order to ease cognitive load on getting started, something which My hunch is that we might give it a shot as it is now and see where we end up; nevertheless, feel free to hit me with arguments to the contrary! I know, for example, this will be a scaling bottleneck for huge deployments (but we've yet to hit those) PS: the issue after this one: make a plugin/app discovery & install system that's nicer than discourse's (if possible), ie wordpress-like maybe. |
Thanks for the backstory! My argument for having the server only do the API is really just that it gives it reduces the scope and keeps things modular. It makes a potential future rewrite in Rust/Go/whatever easier. It also reduces some risk of future plugins accidentally becoming tightly coupled with the server. The complexity of a plugin system would have to live somewhere, and it'll be extra maintenance work in either SpeckleServer or another project. That said, I probably don't have much appreciation for how much work it might be to maintain another project. Plus, it'd always be possible to separate out the server from plugins at a later point, if a compelling reason (performance? security?) appeared. |
Did some work, currently it looks like this:
& added in the |
Step 0:
Right now plugins need to be registered manually in
server.js
. We should have a system whereby on startup we scan all top level folders of thenode_modules
folder and look for anything that contains a speckle plugin manifest file, eg.speckle-plugin-manifest.json
This manifest file should contain basic info about the respective plugin, ie:
This way third parties can develop their own frontends, publish to npm or the package manager of their choice, and then simply do
npm install speckle-dashboards@latest
to have it running with a live speckle server.The text was updated successfully, but these errors were encountered: