Serve plans pages under localized subdomains

POP-972.md

POP-972: Serve plans pages under localized subdomains

Goal and outlook

Currently plans.spa is a SPA hosted via my.apigateway.lambda which is served via the my.babbel subdomain and does not add to our localized subdomain authority. To improve this, we want to serve them via the localized subdomains e.g. de.babbel or uk.babbel.

Future plans are discussed to also move other SPAs to the localized subdomains e.g. ppf.spa, authentication.spa

Constraints

my.apigateway.lambda

• we do not want to maintain a forked version of my.apigateway.lambda
• migrating SPAs from my.apigateway.lambda to localized.my.apigateway.lambda should be simple (e.g. no path manipulation)

SPA

• plans.spa relies on the locale in the path (which is not equal to the subdomain)
• a fallback URL per locale needs to be in place

in general

• locales and subdomains are not exact matches, a mapping needs to happen
• we want to be able to run the SPAs for a short amount of time in both subdomains in parallel to enable indexing via canonical link tags. After that they should only be available in the localized realm

Dependencies

When building this based on the current architecture, we have dependencies with the following repositories / teams:

• my.apigateway.babbel

  • build as a backwards compatible clone of my.babbel (multi-purpose) app with features we do not need e.g.
    • support of routes without locale in the path
    • rendering with frame.spa
  • owned by DarthVader for the purpose of logged-in users in focus
  • we might introduce the same issues we had with the US team on PPF, since we might have not matching / diverging requirements

• static.apigateway

  • entry point for the routing of the localized subdomains (inevitable)
  • owned by DeliveryHeroes and used by the US team too

Suggested approach

Moving plans.spa into a microverse will enable us, to be independent of my.apigateway.lambda, by introducing a slimmed version of the lambda, that only contains the features, we need. We can also reduce complexity in the build and deployment process, by avoiding to fetch commitSHAs as reference to the version of plans.spa from a DynamoDB and instead bake the reference as a local reference when building the artifacts for the server to provide the html for our app.

Features from my.apigateway.lambda we need

• deal with AWS session management
• setting cookies
  • babbeltrackinguuid
• checking for user session
  • _accounts_babbel_session and remember_account_token cookie
• requesting client info and geoip info from APIs
• rendering a page and inject our js package
  • meta tags
    • hreflang
    • viewport
    • cache control
• rendering error pages or redirecting to other error pages (!!)
• providing data-config via ENV variables specified in terraform (e.g. apigateway_base_url)

Timeline

• creating a proof of concept that simplifies the entry point for the SPA drastically
  • avoiding unneeded API calls (e.g. user-settings)
  • removing conditional statements
  • using values instead of configuration (e.g. for the SPA artefact, meta tag headers)
  • no use for a framework (express might be overhead for this)
• build a working version on staging
  • create infrastructure for the project
    • terraform
      • github repo,
      • CDN origin with the correct subdomain => locale mapping
      • lambda function
      • S3 bucket
    • travis project
    • webpack setup for generating and uploading the artefacts

Open questions

• do we want to send tracking events for e.g. request:performed? What about logs?