Laskar: High-Velocity GraphQL & Lambda-based Software Development Model

Sale Stock Engineering, represented by Garindra Prahandono, presented "High-Velocity GraphQL & Lambda-based Software Development Model" @ BandungJS on May 14th, 2018.

Does this sound interesting to you? Join us to build more things like this! Check out: https://careers.salestock.io

Transcript

2. High-Velocity GraphQL & Lambda-based Software Development Model
3. Who are we?
4. Sale Stock - Overview • E-commerce founded in late 2014 ◦ Internal Engineering founded in early 2015 ◦ Launched our in-house website in mid-2015, app in late-2015 • Concentrated on women's fashion ◦ Around Rp 100rb range as opposed to > Rp 200 range ◦ Recently expanded to men’s fashion and women’s lifestyle
5. Sale Stock - Overview • US$ 27 million Series B mid-2017 • Doubled revenue since then • Margins comparable to European vertically-integrated unicorns ◦ ASOS ◦ Zalando ◦ Boohoo.com ◦ etc. ◦ Margins still improving
6. Top Shopping Play Store Rankings
7. Top Applications Play Store Rankings
8. Sale Stock - Multi-Layered Defensibles • Vertically-integrated • Business layers (all done in-house): ◦ Merchandising ◦ Manufacturing ◦ Logistics ◦ Customer Service ◦ Finance ◦ Etc. • Inject software and automation in every layer of the vertical integration
9. Sale Stock - Multi-Layered Defensibles • This translates to a *LOT* of software • ~15 user-facing applications internally, ~200 services ◦ Most of these will be successful products if SaaS-ed • BUT, decided to be simple organizationally ◦ Want to financially make sense ◦ 30+ software engineers, ~60 total in Engineering ◦ A small team given the scale and diversity of portfolio • How to do these without killing the engineers? Better tooling.
11. GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data.
24. GraphQL • No overfetching, no-underfetching • Super easy versioning ◦ Single endpoint to maintain ◦ Maintenance and deprecation can be done at the per-field level ◦ Easy to support years-old clients this way • But… • Performance is a problem if not taken care of (a bit of a longer story) • You’re still coding -- we can make this simpler!
25. Laskar Automatic GraphQL CRUD-based logic generation tool
26. Laskar - Architectural Breakdown • Schema • Gateway • Persistence • Lambda • Interface
28. Laskar - Schema • Primary way developer inject behavior into the platform • Developers write a declarative, YAML-based manifest file called SDML (Sale Stock Domain Markup Language) -- no explicit imperative-style coding • Entity is a core concept declared in the SDML
29. Laskar - Schema
30. Laskar - Schema • Entities are stored in the SQL-compliant persistence layer as a table • Entities have “stored” properties ◦ will be mapped to SQL table fields • GraphQL CRUD queries and mutations will automatically be “generated” for these entities ◦ get<Entity>, create<Entity>, edit<Entity>, delete<Entity>, get<Entity>List, etc. • Can also replace some straightforward SQL filtering logic • Replaces tons of boilerplate -- can be thousands of lines of code! ◦ Controller ◦ DAL ◦ etc.
31. Laskar - Schema
32. • Can also express SQL-based filtered reads! ◦ Implements WHERE and SORT BY clauses ◦ GraphQL query is instantly available ◦ Index is automatically created for the filtered and sort fields ◦ Good performance is automatic -- one less thing for developers to take care of ◦ Value caching (provided by the cache layer) is also possible if you need the extra performance
33. Laskar - Schema • End-to-end Development flow is all integrated within a tool ◦ Local development ◦ Schema migration ◦ Schema deployment
34. Laskar - Schema
35. Laskar-Gateway
37. Laskar - Gateway • A horizontally-scaled set of a GraphQL-compliant server • All Laskar-based requests (e.g. from front-end code) will go through a single endpoint served by these servers. • Dynamically performs GraphQL “behaviors” (queries, mutations, types, etc.) based on currently-active Schema. • Schemas are synced in realtime to the Gateway
38. Laskar - Schema
39. Laskar - Gateway • The simplicity of the Gateway gives us: ◦ No binary / image deployment! (deployment is just a schema update!) ◦ No more extra running processes for each service ◦ Free distributed tracing and observability in general! (since all sub-requests are made by the gateway) ◦ Uses Envoy-based sidecar for network resilience handling ▪ Automatic timeout handling ▪ Sophisticated request load balancing ▪ Circuit breaker
40. But what if my use cases extend beyond CRUD? What if I want to have “funkier” logic?
41. Lambda
43. • Once you want to put custom logic, Lambda’s the answer • A few integration points: ◦ Entity’s computed properties ◦ Root queries • Entities can have “computed” properties (as opposed to “stored”), if you want the properties to be computed on the fly with a Lambda ◦ Product { score } • Top-level queries that are outside of CRUD boundaries: ◦ getTrendingProducts (needs access to data-intensive service) Laskar - Lambda
44. Laskar - Lambda • What is it? ◦ A predefined, local function (sum, takeFirst, etc.) ◦ A remote call ▪ To a microservice ▪ To a Cloud Function
45. Example query:
46. Declare a computed Property in SDML:
47. Declare the Lambda:
48. Implement the Lambda logic:
49. Persistence
51. Laskar - Data Persistence • All entities’ stored properties are stored here • Uses CockroachDB ◦ NewSQL ◦ SQL ACID capabilities, but with almost-linear NoSQL-like scaling capabilities ◦ Add node for additional capacity -- simple scaling ◦ Simple, Cassandra-like symmetrical node architecture • Simple caching layer ◦ Can cache: ▪ Lambda return values ▪ Stored properties ◦ Invalidation is automatic (post-mutation) or TTL-based
52. Laskar - Query Lifecycle
53. Laskar - Query Persistence • GraphQL queries have to be pre-registered (termed “Persisted Query”) • On build time, GraphQL queries are extracted out of source code, hashed, and sent to the server for persistence. IDs are then assigned to each query. • On production, queries are then not sent on its raw text form, but only its ID
54. Laskar - Query Persistence • On production, queries are then not sent on its raw text form, but only its ID • Increases security and performance
55. Laskar - Query Planning • Much like a SQL database, prior to execution, upon request, query text is transformed to a Plan. • Steps: ◦ Query parsing to AST ◦ AST conversion to Plan ◦ Plan caching • Let’s visualize.
60. Laskar - Query Planning • Query planning is done only once per query-ID -- after which the plan output is cached. • Subsequent query for that ID uses plan from the initial planning. • Plan caching improves performance -- CPU usage is historically extremely low in Laskar-Gateway
61. Laskar - Query Execution • On the same stages, multiple requests to stored properties are de-duped and batched into a single SQL query to the persistence layer. • Requests to similar lambdas are also de-duped (with some caveats). • Automatically uses cached data for SQL-layer load-shedding.
62. Laskar - Interfaces
63. Laskar - Interfaces • Admin interfaces for the data can also be created automatically • No need for developers to write React / front-end code • Everything is derived from the schema inspection and a simple config file.
64. Laskar - Interfaces
65. Laskar - Where is it used currently? • Sale Stock homepage! (specifically the banner management system) • Product category management • Image management system • Promotion & landing page management system • Many more in the pipeline!
66. Laskar - Benefits • Much fewer lines of code -- virtually no boilerplate • Can be used in 60-70% of use cases ◦ If it’s simple CRUD, then it’s used • Instant performance -- easy caching, indexing ◦ Index creation is automatic ◦ In the declaration, possible queries are defined upfront -- possible to force-create indexes. ◦ Reduces the number of avenues for possible developer mistakes ◦ Caching is as easy as a one-liner -- invalidations are automatic
67. Laskar - Benefits • Automatic schema migration • In one case, 20k lines of code were replaced by < 300 lines of YAML code -- identical feature set • Instant deployment • Huge hardware requirement savings ◦ No set of new hardware needed for each new feature ◦ Especially for low-traffic feature uses • Non-programmers can theoretically implement features
68. That’s it!
69. We’re Hiring! Some of our team members hail from:
70. Careers • We’re hiring! • Practically all zaman-now startup positions are available, but highlighting two: ◦ Front-end Platform Engineer ◦ Data Platform Engineer • https://careers.salestock.io
71. Careers - Front-end Platform Engineer • Join a team with a knack for the bleeding edge • We used: ◦ React in early 2015 (with in-house server-side rendering) ◦ RN in early 2016 ◦ GraphQL in early 2016 ◦ Single-codebase web/app React+RN in early 2016 ◦ Uses Apollo in late 2016 • Knack for implementing custom tooling where it makes sense ◦ Laskar and lots of other internal tooling • Write apps for millions of users
72. Careers - Data Platform Engineer • Join a team that’s building a next-generation data platform that empowers data scientists, analysts, and software engineers to smoothly collaborate and fully-own their data science and pipeline. • We craft and create the end-to-end platform with: ◦ Jupyter Notebook ◦ Apache Spark ◦ Google Dataflow, Dataproc ◦ Google BigQuery ◦ Tensorflow ◦ Kubeflow ◦ Kubernetes ◦ Lots of custom tooling
73. Thanks! Q & A?