Skip to content

Latest commit

 

History

History
138 lines (125 loc) · 5.9 KB

TODO.md

File metadata and controls

138 lines (125 loc) · 5.9 KB
Raw
  • Tighten up the specs- look for required variables, etc.
  • Get rid of unused/useless scripts. Ensure those that remain have useful names.
  • Lint SQL
  • Lint JS
  • Test request/response validation framework
  • Errors framework- two examples exist: check what's done in central dir and quotes
  • Response framework, including response validation and signing
  • Make it so we can exit docker run with . Might require handling interrupts in the node process?
  • Allow the user to somehow generate a template .env file from the pulled container image. Perhaps:
    • create an admin route that generates a template .env file, then the user can curl the output of that route to create a template .env file

Passphrase generator inspired by https://github.com/aaronbassett/Pass-phrase, and word files taken from there. It's MIT licensed, so we need to meet the conditions of the MIT license in this repo.

Health check route that checks db conn and any other operating dependencies. Perhaps return handling stats or something if there's time.

Openapi Spec

All routes requestBody properties should have a required:true property where appropriate. These are missing from many request bodies which are just json schema refs.

Consider changing all references to /{Type}/{ID} to be /MSISDN/{ID} Consider removing unused/unimplemented routes

Add allowAdditional: false all over the API? Or create this property it in our validation framework so that ajv rejects all requests with additional data/headers/query params etc.?

The converter from swagger to openapi3 was faulty. Specifically, it removed anything in brackets {} from description strings. There may have been other problems. Find another converter, or go through the converted spec and manually verify the contents.

Put the final spec into the swagger editor https://editor.swagger.io/.

The POST /quote example in the simulator API spec contains an invalid transactionType.subScenario

Put callbacks into the routes? Use those to validate the callbacks? It's worth really thinking about whether this is sensible, because all callbacks are already documented in the API.

Shared repos

Options

  • private npm registry- https://docs.npmjs.com/misc/registry
    • Pros:
      • No public access to code
      • Normal API
    • Cons:
      • No idea how difficult this is likely to be
      • Support burden
      • May have to manage data persistence
      • Risk of publishing to public NPM
  • public npm? (are there restrictions on allowable licenses, i.e. MIT/GPL etc.?)
    • Pros:
      • Low maintenance
      • Super-easy
      • Normal API
    • Cons:
      • Public access to code
  • Public Github repo
    • Pros:
      • Low maintenance
      • Super-easy
      • Normal API
    • Cons:
      • Public access to code
  • Azure Blob Storage + VPN + IP-restricted, expiring access token + npm pack + Azure CLI publishing of packages (in Makefile). Can the access token be generated by the CLI? Can a single access token be used for multiple files?
    • Pros:
      • Well-supported APIs, should be low-maintenance
      • No risk of publishing to public NPM
      • Granular control over code (IP whitelist the VPN)
    • Cons:
      • Up-front development effort, perhaps 1 day, depending on ease of Azure Blob Storage setup
      • Requires more investigation; may be deemed to be non-viable for reasons mentioned above
  • Use Gitlab, which supports single-repo read-only access tokens. Consider using Gitlab repos as "slave". I.e. use Github as the primary source of truth but publish to a Gitlab upstream and use that upstream for only npm install. Push to it when the version of an npm package is to change.
    • Pros:
      • Same as "Public Github repo"
    • Cons:
      • Partial departure from Github
      • Somewhat confusing and onerous from a development perspective
  • Continue with the same approach as currently; using a buggy, unpleasant, untrustworthy Dockerfile. Consider using a deploy key without a password?
    • Pros:
      • Copy-paste the existing solution, easy
      • Deploy keys can be revoked
    • Cons:
      • Individual SSH keys are put into the container
      • Building a docker container is error-prone if the key requires a password
  • Find/create a super-dumb file server. Host it on a single Azure VM. Not really a wonderful solution, mostly because a custom implementation requires more testing.
    • Pros:
      • Should be reasonably easy
    • Cons:
      • Maintenance burden
      • May have to manage data persistence
  • Commit node_modules...
    • Pros:
      • Easy
    • Cons:
      • Large amounts of redundant code in the repo
      • High potential for incompatibility between systems (i.e., systems that use glibc vs musl, or another libc, systems with different instruction sets).
  • Copy node_modules to the container- probably a pretty bad idea, especially if there are native dependencies.
    • Pros:
      • Easy
    • Cons:
      • High potential for incompatibility between systems (i.e., systems that use glibc vs musl, or another libc, systems with different instruction sets).
  • Github deploy key
    • Pros:
      • Not very difficult
    • Cons:
      • Requires some setup (getting the deploy key) on the developer's behalf
  • Verdaccio, private npm proxy: https://github.com/verdaccio/verdaccio
    • Pros:
      • Should be reasonably easy
    • Cons:
      • Maintenance burden
      • May have to manage data persistence
  • Move to a monorepo
    • Barely a serious suggestion, really..
  • Commit .tgz dependencies. Have a Makefile rule to update them?
    • Pros:
      • Easy
    • Cons:
      • Large amounts of redundant code in the repo