$customHeader
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1

Adam Stankiewicz, Greg Sham (Deactivated), Brittney Exline (Deactivated), Robert Raposa, Douglas Hall (Deactivated), Nimisha Asthagiri (Deactivated), Ari Rizzitano (Deactivated), George Babey, Zachary Rockwell (Deactivated)

Portal Status

  • "POC++"
  • Static frontend, no webserver dependencies, can be deployed anywhere
  • Working entirely locally right now
  • Sandbox deployment (nginx + static serving)

Portal Needs – First Cut

  • Application code deployed to some location
  • Application code accessible by anyone on the internet
  • Enterprise will make use of subdomains
  • Enterprise customers may upload custom assets (logo, stylesheet, etc) as well which will be served from a separate location
  • Logging and monitoring

Hosting

  • Options:
    • Deploy to S3 bucket
    • Host assets from a dedicated server
  • S3
    • Access logs: where are assets pulled from?
      • May be pulled into Splunk
    • NR browser monitoring – React agent
      • Pricing is usage-based
      • NR agent enables custom events
    • Caching?
      • S3 can set cache headers (TTL) to be monitored by a CDN
      • API endpoints should be thoughtful about caching behavior
      • Blue-green?
        • CDN API enables this, but we have no prior art
        • Will this incur cost?
        • Retention policy?
      • Versioned individual files
      • How to bust the client cache between deployments?
    • Terraform
      • Define bucket, lifecycle, etc.
    • Environments
      • Each env (stage, prod, edge, sandbox?) should have its own bucket
    • Permissions
      • Be smart about this
    • Downside: sandboxes will be different
      • nginx can "play" CDN
      • Dump application static assets on the sandbox, use nginx to specify application static assets location
  • Hosting assets from dedicated server?Heading 3

Permissions

  • CORS
    • Hitting endpoints across different services is a potential pain point
    • If enterprise will be using subdomains, *.edx.org rules should work
    • Trial balloon:
      • What level of CORS wildcarding can we get away with? How will CORS interact with org-specific subdomains?
    • Do we have any restrictions on other static assets that will be served via this frontend?
      • Images - we're probably OK
      • Fonts, JS, styles – probably OK
      • Should we deploy images to a different domain (to set page-specific rules?)
  • Iframe security policy on LMS?
    • Probably fine. Very permissive

Configuration

  • Baked into individual application asset builds
  • "Stage assets", "prod assets", etc.

Build MVP

  • Set up build environment
    • npm, repos cloned, etc.
  • Jenkins vs. GoCD
    • Jenkins flexibility: deploy any branch
    • GoCD: deploy specific branch, must edit pipeline itself to change. Rigorous!!
    • Maybe talk to Platform team also
  • Set up buckets
    • Terraform
  • Test suite
    • e2e/smoke tests
    • Contract based testing?
    • Potential areas of exploration around JS-based e2e tests
    • Tests should live alongside portal code
  • CDN configuration
    • Start with Cloudflare defaults, evolve as necessary
  • Subdomain setup
    • Follow-up about this

Next Steps

  • No labels
$customFooter