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.

Transcript

1. How building BHIM pushed us into Functional Programming using Haskell / PureScript Vimal Kumar
2. If we can build BHIM in 3 weeks, - Why not in 1 Week? - Specification → Application
3. 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
4. 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
5. Need to Create a Nationwide Consumer interface for UPI on Smart phones (BHIM) and Feature phones (*99#) in 3 weeks! Dec 2016 - BHIM happens
6. 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
7. • 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!
8. 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
9. Two weapons 1. Functional Programming 2. Collaborative creation This talk focuses on (#1) - Whys, Hows of FP
10. • 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
11. 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
12. • Presto UI used as a prototyping tool • Hyper parallel development using JS-FP techniques for the backend • *99# What we did in 3 weeks
13. Started FP in Javascript - Monads!
14. 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.
15. We built PRESTO flows using PureScript After BHIM - The Quest for Specification → Application Continues
16. 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
17. 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.
18. 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.
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. Bring Pure FP to Mainstream School of Functional Programming
29. 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
30. Presto - Roadmap • VR Code Browser - Sketch Plugin, Flow editor, Type editor • AI - Common Code Pattern Finder
31. 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
32. Thanks! vimal@juspay.in