The New Hoodie Architecture

new-hoodie-architecture.md

// this is a draft of an outline of an result of an in-person meeting that will eventually live in a GitHub issue for the community to discuss, this is just to vet the outline with the in-person meeting members.

New Hoodie Architecture

This is going to be a long one, grab a nice beverage and enjoy the ride :)

Table of Contents

• Motivation

  • Making work on and with Hoodie easier and more fun
  • Automate all the boring things
    • benefit from computers enforcing consistency
  • target audiences
    • end users
      • easier to make a new app
      • easier to maintain an app
    • new contributors
      • making it easy and fun to get involved with hoodie
      • optimise for short time to first success
    • devs
      • making it easier and more fun for us
      • proper release engineering

• The New Hoodie Module

  • no more grunt
  • sub-READMEs
  • unified package.json // enforced by pre-commit-hooks
  • unified commit message conventions // enforced by pre-commit hooks
  • simple auto-install of pre-commit-hooks

• Testing

  • modules only get per-module tests
  • the hoodie module will have integration tests
  • the major version number is tied to these tests and their BC breakage

• The hoodie Module

  • ties together hoodie-server & hoodie-client etc as peer dependencies
  • has cli tools, replacing the global hoodie-cli tool
    • npm run hoodie start
    • npm run hoodie bundle
    • etc.

• Plugins:

  • plugins are installed top level, and loaded from dependencies in package.json
  • frontend plugins now use require()
  • hoodie.js is packaged in 4 ways:
    • hoodie.js
    • hoodie.min.js
    • hoodie.browserify.js
    • hoodie.browserify.min.js
  • packaging of hoodie*.js happens at release build time, so the first run experience is fast. Changes to plugins cause a recompile on server start (using hapi-browserify instead of our custom code)
  • plugins get reorganisation:
    • ./client/index.js: frontend code (formerly ./hoodie.pluginname.js)
    • ./server/index.js: backend code (formerly worker.js or package.json main)
    • ./server/hooks/* hooks, formerly ./hooks/
    • ./admin-dashboard remains
    • (as per require() rules, these could also be ./client.js, ./server.js ./server/hooks.js, but those are discouraged)

• The New Hoodie Module Dependency Tree

  • new module names
  • split m-f-h into hoodie & hoodie-app-*
  • module migration
  • deterministic builds
  • npm install hoodie

• The New hoodie-server layout:

  • more peer dependencies
  • fold in hoodie-plugins-manager & hoodie-plugins-api
  • remove nodejitsu & localtld code

• Releases

  • next tags
  • new hoodie release on any sub-component bump
    • CI tests show any breakage
  • release new Hoodie version periodically

• The Hoodie Internals Documentation

  • document design/decision making process (RFCs like Ember)
  • document development process
  • document release process
  • document Hoodie architecture (kinda this document)
  • combine generated API docs from hoodie-client sub-modules

👍