Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
The New Hoodie Architecture

// 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

This comment has been minimized.

Copy link

@christophwitzko christophwitzko commented Jul 14, 2015


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment