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

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

High-Velocity GraphQL & Lambda-based Software Development Model

Slide 3

Slide 3 text

Who are we?

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Top Shopping Play Store Rankings

Slide 7

Slide 7 text

Top Applications Play Store Rankings

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

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.

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

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!

Slide 25

Slide 25 text

Laskar Automatic GraphQL CRUD-based logic generation tool

Slide 26

Slide 26 text

Laskar - Architectural Breakdown ● Schema ● Gateway ● Persistence ● Lambda ● Interface

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Laskar - Schema

Slide 30

Slide 30 text

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, create, edit, delete, getList, etc. ● Can also replace some straightforward SQL filtering logic ● Replaces tons of boilerplate -- can be thousands of lines of code! ○ Controller ○ DAL ○ etc.

Slide 31

Slide 31 text

Laskar - Schema

Slide 32

Slide 32 text

● 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

Slide 33

Slide 33 text

Laskar - Schema ● End-to-end Development flow is all integrated within a tool ○ Local development ○ Schema migration ○ Schema deployment

Slide 34

Slide 34 text

Laskar - Schema

Slide 35

Slide 35 text

Laskar-Gateway

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Laskar - Schema

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

But what if my use cases extend beyond CRUD? What if I want to have “funkier” logic?

Slide 41

Slide 41 text

Lambda

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

● 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

Slide 44

Slide 44 text

Laskar - Lambda ● What is it? ○ A predefined, local function (sum, takeFirst, etc.) ○ A remote call ■ To a microservice ■ To a Cloud Function

Slide 45

Slide 45 text

Example query:

Slide 46

Slide 46 text

Declare a computed Property in SDML:

Slide 47

Slide 47 text

Declare the Lambda:

Slide 48

Slide 48 text

Implement the Lambda logic:

Slide 49

Slide 49 text

Persistence

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

Laskar - Query Lifecycle

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

Laskar - Query Persistence ● On production, queries are then not sent on its raw text form, but only its ID ● Increases security and performance

Slide 55

Slide 55 text

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.

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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.

Slide 62

Slide 62 text

Laskar - Interfaces

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

Laskar - Interfaces

Slide 65

Slide 65 text

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!

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

That’s it!

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

Thanks! Q & A?