Alice in Hydra land

guide for hydra/front-end development

Agenda

  • Scaffold
  • Rolling out a feature
  • Implementation
  • Styling
  • Testing! (unit + e2e)
  • Future plans

 

Scaffold/hydra

Problems

Health check failures

  • 2 instance running same time

    • Varnish ESI tag resolve operation not atomic

    • non-ESI endpoints RR load balanced

  • no "hot switch" (stop, update, restart)

 

Local pre-prod scaffold usage

  • experimenting area, sandbox
  • very difficult to test experiments with builds
  • development blocked when something goes wrong

...

Rollout plan

  • experiments
    • http://drjekyll.corp.skyscanner.local/experiments
    • fbExperimentService, fbExperiment
    • <span fb-experiment="fbw_test == 'b'" />
  • features
    • fbFeatureService, fbFeature
    • <span fb-feature="fbw_test" />
  • use them in megatron
    • pass everything as feature/booking (booking request)
    • pass experiments only if they are switched on
      • example in feature service

 

Internals

  • state management
    • hydra asks for "steps" upfront
    • every step is a state (+ couple "hidden" states)
    • custom state machine implementation in angular
  • hydra asks platform for the next step "specification"
    • JSON schema -> render the form for that step tailored to partner
    • posts back the data
  • end states
    • failed: oops something...
    • unconfirmed: dunno what happened
    • confirmed: booking went through
    • accepted: booking request made, still waiting for the actual booking (usual OTA flow)

 

Payments

  • braintree
    • renders an iframe, tokenize card number
    • we don't get access to card number in our stack, stays in BT domain
    • a proxy will replace a placeholder to card number during partner communication
    • maintain PCI compliance
    • apps?
    • https://confluence.skyscannertools.net/display/HDB/Direct+booking+payments

 

Implementation

Directory structure

  • codebase split based on "modules"
    • entities belongs together
    • controller, directive, template
    • angular team recommendation
  • navigation -> ctrl+f
    • file naming conventions
    • {name}-directive.js
    • {name}-controller.js
    • search for angular names

Javascript/angular patterns

  • use references in binding expression
    • {{ model.value }} instead of {{ value }}
    • model might change in time, reference remains same
  • defensive coding a.k.a "null checking"
    • if (something) { something() }
    • can break the form -> oops page
    • use it wisely (is it likely that the object ever be null?)
      • objectpath
  • offloading
    • this context: "can't we do it in megatron?"
    • the same codebase runs for mobile and desktop

 Patterns - 2

Testing

  • No change should be released at least without unit test
  • Good coverage (with meaningful tests) -> More confidence! 

 

======== Coverage summary ========
Statements   : 90.71% ( 4314/4756 )
Branches     : 81.38% ( 1840/2261 )
Functions    : 87.9% ( 908/1033 )
Lines        : 90.69% ( 4306/4748 )
==================================

E2E

  •  e2e testing tool: protractor
    • built for angular
    • selenium based
    • use "helpers" to handle animations etc...
  • test runner: saucelabs :(
    • very slow for our use case, unstable
    • transition to Browserstack is in progress (waiting for contract)
      • 5x faster
    • be patient please!

Styling

  • Our language: SCSS
    • syntax sugar over CSS
  • Mobile first
    • we build css for mobile
    • overwrite properties for desktop (media queries)
    • tons of helpers/examples in hydra
  • Backpack (docs)
    • we should aim using backpack css mixins/properties
    • effortlessly sync look and feel
    • whatever we do: "is it in backpack?"
    • only css support at the moment

Branding

  • every airline is branded
  • dbook branding API
    • host brand configs (JSON documents)
    • build separate branded css based on configs for every partner
    • use partner specific CSS for branded partners
    • issues
      • not scalable -> build time increases every time adding new partner
      • configs not maintainable, no easy way to change every partner header colour e.g
      • too many colours
  • transition to skyscanner branding API is on a roadmap

Future plans

  • Getting rid of scaffold
    • dbook is going to be a microsite
  • Is hydra too big? Should we split it, how?
  • Component based front-end
    • component is like "seat-selector"
    • ties in well with OC approach of the company
    • components can use whatever JS, css framework
    • no need to "rewrite" -> incremental
  • First step: how we're going use react/backpack components from angular
    • angular especially bad for DOM manipulations -> react is a massive performance improvement

Q & A

Made with Slides.com