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

Transcript

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
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
33. Edge Architecture
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.
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!