simplify Internal Module Architecture

Progress overview, find background info below

• https://github.com/hoodiehq/hoodie-log/issues/31
• https://github.com/hoodiehq/hoodie-connection-status/issues/46
• https://github.com/hoodiehq/hoodie-store/issues/1
• https://github.com/hoodiehq/hoodie-store-server/issues/32
• https://github.com/hoodiehq/hoodie-store-client/issues/90
• create hoodie-account repository / module as in https://github.com/hoodiehq/hoodie-store/issues/1
• migrate hoodie-server-account / hoodie-client-account as in https://github.com/hoodiehq/hoodie-store-server/issues/32 and https://github.com/hoodiehq/hoodie-store-client/issues/90

Once all released

• update hoodie-client package.json
• update hoodie-client README.md (links to repos)
• update hoodie-client/lib/get-api.js
• update hoodie-server/lib/hapi.js here and here
• update hoodie’s README.md with new architecture

---

Today we have this for new Hoodie

hoodie/
├── hoodie-client
│   ├── hoodie-client-account
│   ├── hoodie-client-connection-status
│   ├── hoodie-client-log
│   └── hoodie-client-store
└── hoodie-server
    ├── hoodie-server-account
    └── hoodie-server-store

Additionally there are these two repositories:

• https://github.com/hoodiehq/hoodie-standalone-account
• https://github.com/hoodiehq/hoodie-standalone-store

We use these to test client & server together and have a simple generic web app UIs.

The problems with this architecture are

• the standalone repos are overhead and confusing
• it’s pretty hard to anderstand how e.g. hoodie-client-account interacts with hoodie-server-account. Like where are the two coming together, exactly
• It sounds / feels unnaturl. hoodie-client-account, when talking in natural language is the “Hoodie Account Client”, not “Hoodie Client Account”

What we suggest instead is this:

hoodie
├── @hoodie/account
│   ├── @hoodie/account-client
│   └── @hoodie/account-server
├── @hoodie/store
│   ├── @hoodie/store-client
│   └── @hoodie/store-server
├── @hoodie/connection-status
└── @hoodie/log

This architecture combines all logic for the different places that Hoodie touches into one place. Right now that is server & client logic, but in future that will be an admin UI and a generic app UI. This will make the “standalone” repos obsolete too, the role of hoodie-standalone-account is now covered by @hoodie/account

All these core modules follow the same folder structure. All folders are optional.

@hoodie/<module-name>
├── README.md
├── package.json
├── client
│   └── index.js
├── server
│   └── index.js
├── public
│   └── index.html
└── admin
    └── index.html

• client/index.js, exports a Hoodie client plugin, it will be added dynamically to the /hoodie/client.js bundle
• server/index.js, exports a hapi plugin with server logic
• public/index.html and all other assets in public/ will be served at /hoodie/<module-name>/. So for example @hoodie/account could come with it’s own generic account UI to sign in / sign out / reset password etc. That way when I build a Hoodie app, I have an account UI out of the box for free.
• admin/index.html will be added to the Hoodie Admin Dashboard – how ever that will work 😃 We can ignore this part for now and get back to it later.

So this will then work exactly the same with Hoodie Plugins, too. Only that they will not be scoped with @hoodie, but probably have a package name prefix like hoodie-plugin-<name-here>

---

I thought a lot about this in the past weeks and months, and finally I feel like we figured it all out, it all make sense

Let us know what you think 😃

[gr2m]

here’s the full code for example/index.js as I got it, the diff might be a bit hard to read: https://gist.github.com/b3d53107b9fddb0a8d55

[gr2m]

I guess we are done 👏 🎉 chapeau Finn 😃