Modularity

Making all the things their own thing

Overview

  1. First attempt
  2. Second attempt
  3. Keeping modules private
  4. Putting this to use



Idea One

Make everything its out repo and connect dependencies

Job-Queue Deps

  1. offload: the brain of job-queue
  2. env-settings
  3. name-badge-pdf-job
  4. team-account-type
  5. vm-multi-room-pdf-job
  6. vm-png-floor-job
  7. vm-email-pdf-job
    1. vm-multi-room-pdf-job

Offload Setup

  • index.js
  • package.json
  • test/
  • test/tests.js
  • Readme.md

vm-Multi-room-pdf-job

  • package.json
  • index.js
  • test/
  • test/?
  • Readme.md

Pains

  • Updating package.json
  • Finding bugs because you can't test



IDEA TWO

Make testable, reused components their own repo

Job Queue Deps

  • offload
  • env-settings



Job-Queue Jobs

Are only used in job queue so lets keep them in job queue



Isn't Offload Only for Job-queue?

Why make it its own repo?




How to keep private repos private?

Example Package.json

 {  "NAME": "JOB-QUEUE",  "VERSION": "1.0.0",  "DEPENDENCIES": {    "OFFLOAD": "GIT+SSH://GIT@GITHUB.COM:ST/OFFLOAD.GIT#V0.4.1"  }}




So? What are we doing with this?




Lets Break each app into its own repo




Api is a repo




App-dot is a repo




FPC is a repo




On-site is already its own repo




So many repos!




But wait, what about st_modules




If a module is used in two apps
make it its own repo




Right tests for it




Write a full readme



Anyone should be able to open the readme and use the module without looking at the code

Modularity 

By Matthew Chase Whittemore

Made with Slides.com

Modularity 

  • 1,427

More from Matthew Chase Whittemore