Lightweight Business Configuration

Problem

An e-commerce has some commercial configuration to update every now and then. For example: what products are in pre-sale, what products are under promotion, etc.

How to enable non-technical roles to update such configuration with minimal effort?

Context

  • Update frequency: once a day
  • Data to change: a handful of products SKU or dates
  • Existing systems:
    • Front-end app
    • Product catalog back-end app
    • Headless content management system (third party)
  • Current path to prod:
    • Continuous Deployment
  • Current solution:
    • Configuration is stored in code as a handful of JSON files inside the front-end app
    • For any configuration change, a support ticket to engineers is created

Solution

Non-technical roles change configuration autonomously using GitHub web interface. image

Security

  • Non-technical roles adhere to the same security practices as engineers (e.g. strong passwords, password manager, 2nd factor authentication, encrypted laptop filesystem, etc.)
  • Non-technical roles have write privileges on the front-end app repository, but not admin ones

Testing

  • Unit tests over the JSON files cover against:
    • malformed JSON
    • content validation (e.g. pre-sale dates in the past)
    • business invariant violations (e.g. avoid duplicates)

Failure and recovery

  • If a non-technical role makes a mistake with a JSON file, then the Continuous Deployment pipeline breaks
  • An engineer reverts the change and then reaches out to the author to fix the issue together

Pros

  • No need to create a dedicated system to handle the commercial configuration
  • Network fault-tolerant: commercial configuration is embedded at build time
  • Unit tests acting as a quality gateway before changes affects production
  • Configuration changes versioned in git

Cons

  • Not custom validation possible in the GitHub web interface (e.g. invalid date format)
  • Basic JSON file manipulation needed by non-technical roles
  • Changes need to wait a handful of minutes to be deployed in production
  • Non-technical roles need to create a GitHub account, per person

Note

Next iterations

  • If the proposed JSON approach suffer from poor UX, the content management system is likely the next step
  • If the business configuration grows in complexity, we have identified a standalone business subdomain. This requires its own back-end system with a UI to configure the changes

Credits

  • Erik Simon: for proposing custom extensions to the content management system as an interesting alternative
  • Lukasz Plotnicki: for helping me to simplify the proposed solution without falling into security traps like locally forking the GitHub repo