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

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

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


  1. None
  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.
  10. None
  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.
  12. None
  13. None
  14. None
  15. None
  16. None
  17. None
  18. None
  19. None
  20. None
  21. None
  22. None
  23. None
  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
  27. None
  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

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

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

  50. None
  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.
  56. None
  57. None
  58. None
  59. None
  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?