Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Front-End Engineering Productivity @ Sale Stock

Front-End Engineering Productivity @ Sale Stock

Sale Stock takes engineering productivity seriously -- we talk a bit deeper about how we implement that in our front-end teams.

This slide deck is presented in Tech in Asia Product Development Conference 2017 and Facebook Developer Circle Jakarta on August 2017.

Does this sound interesting to you? Join us over at https://careers.salestock.io


Sale Stock Engineering

August 12, 2017


  1. Front-end Productivity Engineering @ Sale Stock

  2. Welcome!

  3. Who are we?

  4. Sale Stock • eCommerce focusing on women’s fashion items •

    Became a company in late 2014 • Started as an FB group • Used third-party ecommerce-platform named Sirclo • Mid-2015 launched internally-built website • Now largest women vertical and fashion vertical ecommerce in Indonesia • Bigger than incumbent competitors: ◦ Zalora ◦ BerryBenka • 500+ employees (~150 white collars, ~350 blue collars)
  5. Why care about engineering productivity?

  6. • Sale Stock is a vertically integrated company ◦ Sourcing,

    Designing, Manufacturing, Warehousing, Delivery, Marketing • Sale Stock builds lots of software ◦ Mostly internal ◦ Publicly visible properties are tip of the iceberg -- most of engineering resources are spent internally • Sale Stock doesn’t hire a lot of developers ◦ We run 1000+ containers, 185 microservices with two infra engineers ◦ Team members need to be capable ◦ Give them great environment to work in ◦ Give them well-designed tooling
  7. None
  8. None
  9. None
  10. None
  11. None
  12. None
  13. … and lots more.

  14. How do we make sure we can execute?

  15. Separation of engineering layers

  16. Separation of engineering layers - Engineering in Sale Stock is

    divided into two major parts: - Feature engineering - Platform / Infrastructure engineering
  17. - Build for other engineers - Build framework-level abstractions -

    Decide what third-party frameworks to use - Build custom abstractions / APIs - Build tooling - Performance / productivity measured by contribution to engineering team’s collective productivity: - Aggregate engineering time saved at both the platform & feature layer - General abstraction stability Platform Engineers
  18. Feature Engineers - Build software for end customers - Using

    abstractions built by platform engineers - Performance / productivity measured by contribution to products - Ideas - Speed of iteration - Feature stability
  19. Shared codebase Web & Apps • We don’t have platform-specific

    teams • Write once on React, instant deploy to web and apps with React Web and React Native • Lower level primitives abstraction to render different sets of platform primitives. ◦ <View /> => <div /> ◦ <Image /> => <img /> ◦ <TextInput /> => <input type=text /> ◦ etc
  20. Monorepo - Single git repo for 185+ microservices - Why

    not a repo per service? - Higher project overhead - Less silo-ing of knowledge - Lighter context switching - Easy code sharing without complex internal code registry - Implements trunk-based development - Single “master” branch - Encourage short-lived feature branch per feature, merged into master - Gain iterative culture, deployment safety
  21. Centralized and self-service tooling - Reduce double work & over-scaffolding

    - Reduce Bureaucracy - Bureaucracy: the latency it takes from someone wanting to do something to the time he / she actually is able to do it. - Involves time - Involves organizational complexity
  22. SSI - Internal command line tool - Contains commands to

    easen regular workloads -- gives uniform way across the company to: - Initialize new service source code - Initialize databases - Develop services - Deploys services - Run automated tests - Monitoring - Lots of other things - Allows feature engineers to own services & features end-to-end
  23. SSI - Nice tidbit: requesting for a Redis, MySQL, or

    a Cassandra database with ssi @ Sale Stock takes you: - Under five minutes (one minute in the case of Redis) - talk to exactly 0 person - Bureaucracy nicely dismantled!
  24. Cloud Devbox - Developers within Sale Stock are given a

    personal “devbox” -- remote development machine. - Software developed within Sale Stock increasingly gets more complicated and distributed -- laptop hardware ceiling is quickly reached. - Deployed in the same cluster as the production workloads for higher hardware utilization (using Kubernetes). - Uses FB’s nuclide IDE for remote code editing - Uses syncthing for laptop<-->devbox filesystem syncing.
  25. Automated Test Suite

  26. Automated Test Suite 1. Core Test Suite 2. Comprehensive Test

    Suite 3. Continuous Production Smoke Test
  27. Core Test Execution • Runs on every merge cycle of

    our www codebase • Optimized for the best coverage-over-speed investment ratio • Consists of hundreds of functional test cases • Runs on 20-node test cluster for speedy execution • Results decide whether we execute auto-deploy for latest merge • Deploy the same version to React Native Versioner
  28. Comprehensive Test Execution • Ultra-complete test coverage -- covers much

    more user usage paths • Runs on multiple devices and browsers • Runs periodically out of merge cycle
  29. Continuous Prod Smoke Test • Runs continuously against prod environment

    • Simulates real users • More sane, useful, accurate form of continuous monitoring compared to regular uptime alerting.
  30. Feature Gating

  31. Feature Gating • Allows specific code paths to be activated

    to a subset of users • Reduces chance of bugs to be exposed to large number of users • Allows engineers to be deservedly less cautious about launching faster
  32. None
  33. Edge Architecture

  34. None
  35. None
  36. None
  37. Edge Architecture • All external-origin requests into the microsystem goes

    through an Edge. • All UI applications have their own Edge service counterpart • But how do the edge servers work?
  38. GraphQL • A client-side-to-server data query language • Alternative to

    REST • Allows engineer to fetch exactly what they need (no underfetch / overfetch) • Allows engineer to re-use queries for different features as they see fit • All SS UI applications now use GraphQL for data fetching
  39. GraphQL

  40. GraphQL

  41. GraphQL Object Sharing • Multiple products within Sale Stock needs

    access to the same GraphQL objects • Introduced internal abstraction called Edge Object. • Allows UI engineers to compose edge objects in their UI servers to build out features quickly • Edge Object abstracts the dirty work of talking to single/multiple microservices to fetch the actual data for the particular object -- allowing UI engineers to concentrate on UI.
  42. None
  43. None
  44. None
  45. Tidbits about Loader • Object type’s field-level resolver function --

    last layer of abstraction that talks to the actual microservice holding the data for the field • Does performance optimizations under the hood: ◦ Request deduplication ◦ Request batching ◦ Applies to multiple request contexts (external-origin requests originating from multiple customers can result in a single call to a microservice if they request similar data) • Allows complex objects to be resolved in an quickly-implementable, performant manner
  46. There’s many more.. But that’s it.

  47. We’re Hiring!

  48. We’re Hiring! Some of our team members hail from:

  49. We’re Hiring! Positions: Software Engineer - Infrastructure Software Engineer -

    Frontend Software Engineer - Backend Software Engineer - Quality Engineering Data Scientist Business Intelligence Analyst
  50. We’re Hiring! Competitive salary Company shares Option for working remotely

    Relocation support Skills development support Health benefits cover family Lunch and meals provided Flexible working hours Career development Periodic team gathering Regular company hackathon
  51. careers.salestock.io

  52. Thanks for your time!