Baseline Product Stack

Because all products are the same.
...different industries and/or customers, of course.

 🙃

🥞

What?

  • A reusable, full-stack & automatically deployed product ecosystem:
    • Database
    • Auth
    • API
    • Web
      • Customer App
      • Admin Portal
      • Marketing Site
    • Mobile
      • iOS
      • Android

Why?

  • maximise component re-usability
  • automate everything & raise confidence
  • promote team-wide best practice at all SDLC stages
  • heighten security & accessibility at all layers
  • increase scalability whilst drastically reducing costs
  • accurately isolate billing for customers
  • uplift culture & promote full-stack engineering
  • enrich engineering talent by using the latest technologies and techniques
  • determines collective team opinions up-front, saves time long term

How?

  • Everything is code - infra, config etc.
  • Monorepo - Keep It Simple, Sausage
  • git push = entirely new environment
    • `repo name` + `branch name` determines each unique stack
    • `component name` determines isolated component (quicker deploys, build only what has changed)
  • `prod` zone has production ready config
    • deletion + teardown protection policies
    • higher capacities

Example

prod

non-prod

=

product-a

product-b

product-c

master

master

master

feature-1

stg

stg

stg

feature-2

feature-3

Example cont.

prod

non-prod

product-a

master

feature-1

stg

feature-2

feature-3

  • Product A - Feature 1 stacks:
    • product-a-feature1-auth
    • product-a-feature1-db
    • product-a-feature1-web-app
    • product-a-feature1-web-marketing
    • product-a-feature1-web-admin
    • product-a-feature1-mobile-ios
    • product-a-feature1-mobile-android
  • Product A - Master stacks:
    • product-a-master-auth
    • ...

Important: zero contamination: any stack within feature1 ecosystem, will only reference other feature1 stacks e.g., auth + db

Serverless (Lambda)

  • ephemeral functions that do one focused job
  • devs can look past tangible constraints like memory, processor etc.
  • reactive (event) or targeted (API)
  • pay for what you use, or pay nothing at all

NoSQL (DynamoDB)

  • indexes > relationships
  • more super fast queries > few tailored queries
    • use db for speed, concurrency no longer an issue (see Serverless)
  • Connor McGregor on boxing "Timing beats speed, precision beats power"
    Matt Rowles on Digital products "Speed beats timing, power beats precision"
  • 'streams' enabled - pump events automatically from the database straight to users via websockets e.g., an updated object

React everything

  • sharing react across all clients using yarn workspaces (@t-bomba 🤙):
    • core:
      • core components e.g., auth, user, workspaces etc.
    • web:
      • customer + admin apps: specific web react components
      • marketing
        • nextjs (todo)
    • mobile
      • ios + android: specific react-native components

Websockets

Users will be updated when they need to know 'something' automatically

  1. database updates
  2. database propagates 'stream' event with updated item
  3. lambda is triggered to catch & handle stream event and handle it
    • e.g., find associated connected users and send them a websockets 'message' with updated data
  4. update appropriate react store with new information
  5. user sees updates

Get started

Questions?

Baseline

By Matt Rowles

Baseline

  • 54