Dummy code to inform & discuss the implementation of 3rd party plugins
Extendability was always a crucial feature of the idea behind Hoodie, it’s one of the biggest advantages over closed source or hosted alternatives.
After working on Hoodie for over two years we gained enough understanding of its architecture to rebuild it from the ground up, focusing on maintainability and ease of contribution.
We had to disable plugins and are now working on enabling them again. This repository is meant as a base of discussion for everyone interested to help with its implementation
We can start working on 3rd party plugins for extending client API, the server logic and the web UI immediately. Admin dashboard extensions and background tasks being out of scope for now.
We are trying to finish up these tasks before implementing the plugins to make things easier:
- hapi usage: replace options.db with options.PouchDB
- Treat Hoodie apps like plugins: add support for client/, server/ and admin/ folders. This will allow us to test this plugin just as if it would be an app itself.
hoodie plugins are npm modules. We recommend a
hoodie-plugin-package name prefix, but it’s not required. Folder structure:
├── package.json └── hoodie ├── client.js # or: hoodie/client/index.js ├── server.js # or: hoodie/server/index.js └── public └── index.html
hoodie plugins can extend the Hoodie client, the Hoodie server, provide a web UI for
/hoodie/<name>and extend the Hoodie admin dashboard at
/hoodie/admin(out of scope). Both
- The Server plugin must be loadable via
require('hoodie-plugin-foo/hoodie/server'). A Hoodie server plugin is a hapi plugin
- The client plugin must be loadable via
require('hoodie-plugin-foo/hoodie/client')A Hoodie client plugin can be a function or an object, it will be passed into hoodie.plugin()
hoodie/publicfolder will be exposed at
/hoodie/<name>by the server if it exists.
- The order in which server/client plugins are loaded is
- core modules (account, store, task)
- 3rd party plugins (npm dependencies)
- app plugins
hoodie.plugin.foois passed into the server plugin,
hoodie.plugin.foo.clientis passed to the client plugin.
hoodiepackage is automatically loading all server & client modules unless they are disabled with config (
hoodie.plugin.foo = falsein
- When using the
@hoodie/clientpackages directly then plugins must be loaded and configured manually.
Loading 3rd party plugins would most likely go into server/plugins/index.js. For comparison see how @hoodie/server is loading @hoodie/store-server and @hoodie/account-server.
Loading the web UIs can work the same way we currently load the public folder of @hoodie/account and @hoodie/store. We need to add a check if the folder exists first
The dynamic bundling of the Hoodie client is implemented in server/plugins/client/bundle.js.
This plugin has
hoodie as devDependency. The idea is that plugins can be started
just like apps, and if they have a
hoodie/public folder it will be served, and
the server & client will be extended dynamically (see hoodiehq/discussion#98)