Frontend plugin registration

[didimitrie]

Step 0:

• I've read the contribution guidelines!

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 the node_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:

{
  "name": "Dashboarder",
  "description": "Basic speckle project dashboard creator and viewer",
  "serveLocation": "/dash",
  "index": "dashboard.html"
}

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.

[pearswj]

Maybe check for clashes of serveLocation too!

[didimitrie]

Maybe check for clashes of serveLocation too!
Yes! True that. And compatibilities too. But 🤫i don't want to reiterate semver discussions :) let's pretend we're all 1.x.x compatible and when 2.x.x comes along...

[pearswj]

🤫

[logan12358]

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)

[didimitrie]

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 EasyServer would provide too, at the expense of an extra project to maintain. As things are at the moment, there's nothing stopping from serving the apps differently anyway (both admin and viewer accept a ?server=xxxx url arg to push them away from the root).

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.

[logan12358]

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.

[didimitrie]

Did some work, currently it looks like this:

{
  "name": "Sample Plugin",
  "version":"0.1.0",
  "desc": "This plugin tests plugins",
  "serveFrom": "/sample-plugin",
  "author": "DAS",
  "contact":"test@dimitrie.org",
  "homepage":"https://dimitrie.org"
}

& added in the .env file some default folders where the server scans for potential plugins on load.