Soapbox development roadmap - adhocteam/soapbox GitHub Wiki

In rough descending order of priority. TODO: flesh out descriptions and associate with GH issues. Also, need to group into releases.

  • Activity feed

    • Activity feed table
      • elements: user, time-stamp, notes, app_id
      • user or platform-initiated
    • UI display of records (in desc?)
      • at the user level (for now) across all apps
      • filter down?
    • to-do: mock-ups of the feed to ensure user activities to inform back-end decisions
    • https://github.com/adhocteam/soapbox/issues/68

  • Monitoring / metrics on web UI

    • leverage existing APIs (cloudwatch) coupled with Soapbox-driven metrics
    • Low-hanging fruit: latency (50th%, 95th%), request rate (http codes), utilization (CPU, RAM), network
    • Scope: at application-level
    • Long-term: connect to alerting services/alarm thresholds
    • UI needs: visualizations, d3?
    • Design decisions: stateless (one-time) statuses or over-time metrics? -> gets involved
      • for now: stateless statuses
    • Dev notes/needs: cloudwatch documentation, helpful API-design case i.e. instantaneous -> over-time
    • https://github.com/adhocteam/soapbox/issues/104

  • Centralized logging

    • Thesis: should not need to ssh into instance (danger-danger)
    • Scope: instance level, application level
    • Current-state: Leverage Runit, built-in ability to log to a port
    • Elements: app_id, instance_id
    • UI needs: expose logs to UI (hold-off)
    • References: Kibana, #engineering-chat
    • [shorter-term] considerations: not designing out certain logging providers
    • [longer-term] Considerations: PII scrubbing
    • Gov-connection: PII (SSNs, TINs, Names, Emails, DOBs, etc.)
    • https://github.com/adhocteam/soapbox/issues/132

  • Hosting static web apps

    • Initial approach: repo + a dockerfile (that includes all depdencies e.g. jekyll, hugo)
    • Tasks: creates cloudfront distribution + S3 bucket when creating an app; run docker, copy to s3, invalidate cache
    • https://github.com/adhocteam/soapbox/issues/138

  • Hosting non-web apps (i.e., Slack bots)

  • BYO VPC (gov-connect) (moved up 9/6)

    • When creating a new application, give user chance to supply a VPC ID
    • If VPC ID is supplied, record it in the db (schema change - should probably add this in any case and record the VPC ID when creating a new app the status quo way), and skip creating it (requires change to Terraform config/order of operations/supplying Terraform with variables, also should hit AWS API to confirm it exists)
    • Separately but related, allow the user to supply AWS creds such that we can call AWS API on their behalf to get a list of VPCs to populate the front-end (alternative to them typing in a VPC ID), see issue https://github.com/adhocteam/soapbox/issues/152

  • Secrets management (moved up 9/6)

    • Use AWS KMS to encrypt and provide programmatic access to application secrets, such as database credentials, API keys, etc.
    • Should integrate with configuration
    • Should be auditable by the user
    • Ideally, app gets secrets from a service at boot-time, and secrets are not exposed on the running instance (eg., in env var files for runit, or in memory as environment variables)

  • Automatic TLS (Let's Encrypt/ACME)

  • CDN option

  • Custom DNS

  • Hosting cron jobs

  • CI/CD hooks

  • Feature flags

  • Google Cloud Platform support

  • Azure support

  • Public status page

  • Release management hooks / changelog generation

  • Automatic environment promotion

  • User Groupings

    • Teams, orgs, etc.

  • Notifications

    • 3rd party API