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

Laskar: High-Velocity GraphQL & Lambda-based So...

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

Sale Stock Engineering

May 14, 2018
Tweet

More Decks by Sale Stock Engineering

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. 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
  4. 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.
  5. 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.
  6. 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!
  7. 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
  8. 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.
  9. • 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
  10. Laskar - Schema • End-to-end Development flow is all integrated

    within a tool ◦ Local development ◦ Schema migration ◦ Schema deployment
  11. 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
  12. 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
  13. But what if my use cases extend beyond CRUD? What

    if I want to have “funkier” logic?
  14. • 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
  15. Laskar - Lambda • What is it? ◦ A predefined,

    local function (sum, takeFirst, etc.) ◦ A remote call ▪ To a microservice ▪ To a Cloud Function
  16. 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
  17. 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
  18. Laskar - Query Persistence • On production, queries are then

    not sent on its raw text form, but only its ID • Increases security and performance
  19. 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.
  20. 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
  21. 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.
  22. 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.
  23. 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!
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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