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

JUSPAY - How Building BHIM in 3 weeks, pushed us into Functional Programming

Vimal Kumar
February 08, 2018

JUSPAY - How Building BHIM in 3 weeks, pushed us into Functional Programming

JUSPAY built BHIM in 3 weeks. That experience gave us enormous insight into the art of rapid development of high quality transactional apps. We built Presto framework using Functional Programming (PureScript/Haskell) as a result.

Vimal Kumar

February 08, 2018
Tweet

More Decks by Vimal Kumar

Other Decks in Technology

Transcript

  1. If we can build BHIM in 3 weeks, - Why

    not in 1 Week? - Specification → Application
  2. Before BHIM Bet on UPI | PrestoUI - Our own

    React Native • We always wanted 1-CLICK hardware-less mobile payments in India • Super impressed by the UPI spec and wanted to make it work • Built our own 35kb React Native like JS-Native UI library (Powers millions of txns) • Already working with banks. Hunch about Spec->App as a radical possibility. We wanted PMs / Mumbai-Bankers to code apps
  3. Spec to App, this idea was lingering • Oct 2016

    • Even Before BHIM • Idea of Spec->App • User Journey = THREAD of Execution • Considering ClojureScript • Considering Using Continuations
  4. Need to Create a Nationwide Consumer interface for UPI on

    Smart phones (BHIM) and Feature phones (*99#) in 3 weeks! Dec 2016 - BHIM happens
  5. Challenges • Initial requirement was for a template UPI app

    • But rapidly mushroomed into a full-fledged payments app for millions of users • Lots of unknowns in API, deployment • Needed to be 10x ahead in UI/UX development to create buffer ◦ Multi-language support ◦ Cross-platform support
  6. • LOT of work to be done in a very

    short time! • Multiple Teams & Stakeholders to be managed in parallel (PMs, Devs, Designers, Compliance, Security teams from from Juspay, NPCI, Govt, Banks, Telcos, etc.) ◦ Changing requirements, Lots of Unknowns • Massive Scale & High Reliability need from Day 1 BIG Challenge!
  7. Put Radical Ideas to Immediate practice • Use JS, DSLs

    & pure FP everywhere • Everyone should code (lawyers, PMs..) • PM = Prototyping in hours • Design with the Customer in place The Only Way
  8. • Design/MVP close to production : Eliminate scope for (mis)interpretations.

    ◦ Rapid MVPs : Web USSD, Main Flows ◦ No Wireframes, Fast Designs close to implementation ◦ Extremely fast iterations ◦ Collaboration & co-creation tools • Hyper Parallel Work: ◦ Parallel Design, Development & Testing ◦ Localisation & Accessibility • Avoid all unnecessary delays ◦ Teams external and internal sit together eliminating communication delays and enabling seamless coordination ◦ Daily standup with all the decision makers for quick decisions and unblockers • Clearer and smaller checkpoints ◦ Frequent demos at multiple checkpoints 3 week - Product / Tech Execution Requirements • Designing the Backend for scale ◦ Shared backend between *99# and BHIM ◦ Monadic way • Presto Ui: ◦ Less code, More componentization ◦ Quick Learning curve ◦ Extremely lightweight and dynamic • Manage Uncertainty of External Integrations ◦ Forwarding logic using a Proxy in *99# • Plan for High Reliability from Day 1 ◦ Sharding strategy for 200M users ◦ • Reduce External Access Dependency ◦ Web USSD • Handle Uncertainty of Infra / Deployment ◦ Zero downtime deployment ◦ No to Kubernetes • Monitoring Systems & Analytics
  9. Prototyping With the Customer Select Option 1. Send Money 2.

    Request Money 3. Check Balance 4. My Profile 5. Pending Requests 6. Transactions 7. UPI PIN - Quickly built a prototyping tool for USSD - BHIM APP - Built the UI layer first with dummy data and started acceptance testing - Architecture was extensively discussed and vetted collaboratively with teams in Mumbai, Chennai, Bangalore, using collaborative canvas tools. Collaborative canvas USSD prototyping tool App Prototype with PrestoUI
  10. • Presto UI used as a prototyping tool • Hyper

    parallel development using JS-FP techniques for the backend • *99# What we did in 3 weeks
  11. JS for ALL Really helped! • Unified code for Frontend

    and Backend • PMs and even our Lawyer coded. Eg Multilingual content was diligently collated all the strings and wrote in JS by our lawyer.
  12. We built PRESTO flows using PureScript After BHIM - The

    Quest for Specification → Application Continues
  13. Why Presto? Apps are Hard Unnatural programming model for Business

    Logic • Event based model complicates transactional apps • No clarity of flow of control - too many jumps • Can’t compose flows, smaller to larger, due to async nature
  14. Why are Apps hard? Frameworks focus on Getting started quick;

    Not on fundamentals to Control complexity • Complexity of serious apps is exponentially increasing. • Need a strong theory like Functional Programming / Category theory with extreme focus on composition. • Hard theories need years of investment to get practical advantage.
  15. Why are Apps hard? Fragmented Architecture, Need Unification • Frontend,

    Backend, Persistence, External service integration, Analytics, Business Logic, Infrastructure. • All are handled in different ways. They can be unified with a few simple building blocks.
  16. Presto: Prototyping should be close to Implementation • Using Conversational

    UX DSL • Business Flows as Goal Trees • PureScript - Pure FP, Category Theory • Unify, Only 3 Blocks, UI | Flows | Data
  17. UX Flows as Conversational DSL User System App Welcome Tell

    Ask Ask-Options Ask-Search Ask-Confirm Thank Delight Suggest Cross Sell Notify Fetch Detect Search Commit Track SetTimer Etc.. App The App Weaves a. Conversation between User & System towards a Goal Goal
  18. Business Logic as Goal Trees • Composable Goals! • Understandable

    to non-tech - Designers, Product Managers Introduce Verify Mobile Create VPA Goal: BHIM Onboarding UI: Step 1 Help UI: Step 2 Help UI: Success OR Verify Mobile With OTP Verify Mobile Sending SMS API: Trigger OTP Poll SMS Inbox for OTP More steps Tree extends here… Local API: Send SMS Code Poll Server for SMS Code UI: Success More steps Tree extends here… More steps Tree extends here… UI: Welcome UI: Ask Mobile
  19. Welcome Dilip to the app Ask to pay the DTH

    bill (why not give some incentive!) > Ask to choose DTH Operator. If a lot, let him search > Ask for his Customer ID. Show HELP on where to find the Customer ID > Fetch his Customer Name and latest due bill amount :: LOAD > Show the bill details and Ask to pay SubFlow Collect_UPI_MPIN Commit the payment and Show confirmation status. Cross Sell Ask if he’d like to set up Auto-deduct OR Payment reminder for future bills > Thank Dilip. Goal Tree as a Narrative
  20. DSL Goal Tree - Code Walkthrough dthAppFlow :: User ->

    Flow Unit dthAppFlow user = showUI $ Info.Welcome user >>= fetch Api.DTHOperators >>= showUI List.DTHOperator >>= untilSuccessful $ showUI Form.CustomerId >>= fetch CustomerName >>= fetch Api.LastBill >>= showUI Info.BillDetails >>= captureUpiPinFlow >>= commit Api.UpiTransaction >>= showUI $ CrossSell.PaymentOptions [AutoDeduct, PaymentReminder] >>= autoDeductFlow <|> reminderFlow >>= showUI Info.ThankYou
  21. PureScript - Pure FP • Composition, State Management, Conciseness and

    Clarity • CPS (Continuation passing style) for the DSL Goal Trees • Choice of PureScript - Best of Haskell and JavaScript. • Category Theory - Functors / Monads / Applicatives
  22. Just 3 Building Blocks - Unify • UI Structure -

    Visual Components like React • Goal Tree - Flows as Pure Functions ◦ Represents the entire business logic ◦ Unified Backend and Frontend • Data as Types ◦ Single set of types for Frontend, Backend, UI, Storage ◦ Types mapped to DB data model
  23. Why PureScript and CPS? LANGUAGE OPTIONS ARCHITECTURE OPTIONS PureScript GhcJS

    ClojureScript Haskell Like + Strong FP - Focus on Purity, Composition, Concise. + Types - Few errors, Easy refactoring JS Integration + Solid and easy JS FFI + JS Code Small & Reliable - New and evolving + Implements all Haskell’s features and access to most Haskell Libraries. - Large size JS and not so reliable runtime + Is a Lisp! + Strong Developer community + Proven runtime - Lacks Types - Lacks strong math / category theory foundation of Haskell CPS (Continuation Passing) Elm Architecture / Redux Pure FRP Maps directly to UX flows / flows as conversion funnel. Global state complicates transactional flows vs CPS manages local state in stack More general than CPS but complicates UX flows. Presto will add FRP support in future
  24. Big Benefits - We estimate 10x • Big Change in

    Dev Culture! It has kindled a burning desire among devs to write concise, composable, reusable code. Scale a fresher team without need for traditional Architects. There is a big reduction in stackoverflow usage! • Purity, Types, Composability, FreeM DSL ◦ Dev Speed - Unification/Reuse have drastically improved development speed. ◦ Reliability - Almost Nil bugs with Types ◦ Refactoring - High confidence to try new ideas ◦ Enabling PMs - Concise DSL code has enabled PMs to review code or write pseudocode. • PureScript - JS Interop, Small Compiled JS - small app size
  25. Presto - Roadmap • Visual Programming - Sketch Plugin, Flow

    editor, Type editor • 1-Week Apps | 1-Day mini-apps • Auto API Type Creator & Quick Check • ORM + API - ~GraphQL • Custom Type Errors in PureScript compiler • Web IDE and Remote Collaboration tools
  26. Presto - Roadmap • VR Code Browser - Sketch Plugin,

    Flow editor, Type editor • AI - Common Code Pattern Finder
  27. Presto Roadmap - Reactive system What if entire systems (clients,

    servers, storage, apis etc) are abstracted out as a Reactive system that is composed of functions! CHAT History Format Screen User1 Input User2 Input Formatted Screen Output User Id