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

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

7. 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

8. Sale Stock - Multi-Layered Defensibles
● This translates to a *LOT* of software
● ~15 user-facing applications internally, ~200 services
● 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.

10. 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.

23. 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!

24. Laskar
Automatic GraphQL CRUD-based logic generation tool

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

27. 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

28. Laskar - Schema

29. 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.

30. Laskar - Schema

31. ● 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

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

33. Laskar - Schema

34. Laskar-Gateway

36. 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

37. Laskar - Schema

38. 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)

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

40. Lambda

42. ● 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

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

44. Example query:

45. Declare a computed Property in SDML:

46. Declare the Lambda:

47. Implement the Lambda logic:

48. Persistence

50. 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

51. Laskar - Query Lifecycle

52. 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

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

54. Laskar - Query Planning
● Much like a SQL database, prior to execution, upon request, query
text is transformed to a Plan.
● Let’s visualize.

59. 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

60. 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.

61. Laskar - Interfaces

62. 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.

63. Laskar - Interfaces

64. 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!

65. 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

66. 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

67. That’s it!

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

69. 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

70. 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

71. 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

72. Thanks! Q & A?