FuelBuddy का कस्टमर ऐप एक Progressive Web App के रूप में शुरू हुआ था। यह Android पर तो चला, लेकिन iOS पर इसे प्लेटफॉर्म की सीमाओं का सामना करना पड़ा: WebKit इंजन की बाध्यताएं, अविश्वसनीय install-to-home-screen, सीमित स्टोरेज, और पुश नोटिफिकेशन क्षमताओं की कमी। FuelBuddy के लिए इसका मतलब था कि PWA भरोसेमंद तरीके से iOS यूज़र्स की सेवा नहीं कर सकता था, और एक स्थिर मोबाइल अनुभव देने के लिए एक नेटिव ऐप ज़रूरी था। मैं उस इंजीनियरिंग टीम का हिस्सा था जिसने ऐप को React Native में दोबारा लिखा।
मैंने किस पर काम किया
- PWA से React Native: ऐप को एक कंपाइल्ड React Native एप्लिकेशन के रूप में दोबारा लिखा, 8 हफ्तों में 14 यूज़र फ्लो में 100% फीचर पैरिटी हासिल करते हुए और iOS व Android दोनों पर एक जैसा नेटिव अनुभव सुनिश्चित करते हुए।
- पूरे स्टैक में काम: मोबाइल फ्रंटएंड पर ध्यान केंद्रित करते हुए ज़रूरी CRUD API सीधे Hasura GraphQL इंजन पर बनाए, ताकि फीचर डेवलपमेंट कभी भी बैकएंड डिपेंडेंसी पर अटका न रहे।
- टीम के साथ शिपिंग: फ्रंटएंड इंजीनियरों और प्रोडक्ट मैनेजरों के साथ करीब से मिलकर काम किया ताकि ज़रूरतों को टेस्ट किए हुए फीचर में बदला जाए और प्रोडक्शन रिलीज़ साइकल तय समय पर रहें।
यह क्यों मायने रखता था
React Native में माइग्रेट करने से iOS और Android दोनों पर एक भरोसेमंद, एकल कोडबेस स्थापित हुआ। 8 हफ्तों में पूरी पैरिटी के साथ 14 यूज़र फ्लो शिप करने से FuelBuddy अलग-अलग प्लेटफॉर्म इम्प्लीमेंटेशन बनाए रखे बिना अपने पूरे मोबाइल यूज़र बेस की सेवा कर पाया।
टीम और ओनरशिप
मैं इस रीराइट पर मौजूद इंजीनियरों में से एक था, फ्रंटएंड इंजीनियरों और प्रोडक्ट मैनेजरों के साथ मिलकर काम करते हुए, टीम द्वारा माइग्रेशन के लिए तय किए गए 8-हफ्ते के विंडो में सभी 14 फ्लो में पूरी पैरिटी हासिल करने के लिए।
GraphQL लेयर
CRUD API Hasura पर चलते हैं, Apollo के बजाय urql के ज़रिए इस्तेमाल किए जाते हैं, GraphQL Codegen टाइप किए गए ऑपरेशन जनरेट करता है, 73 अलग .graphql फाइलें ऐप के असली सरफेस एरिया को कवर करती हैं। लोकल स्टेट Zustand के ज़रिए चलता है, जिसके पीछे तेज़ की-वैल्यू स्टोर के रूप में MMKV है, और Zod सीमाओं पर डेटा वैलिडेट करता है।
लोकेशन और पेमेंट, सिर्फ़ CRUD नहीं
डिलीवरी ट्रैकिंग react-native-maps, एक समर्पित जियोलोकेशन सर्विस, और असली जियोस्पेशियल गणित (दूरी, बाउंड्स, रूटिंग गणना) के लिए Turf.js का इस्तेमाल करती है, सिर्फ़ मैप पर एक मार्कर नहीं। पेमेंट दो स्वतंत्र गेटवे के ज़रिए चलता है: Easebuzz, जिसे रजिस्ट्री डिपेंडेंसी के बजाय एक vendored लोकल पैकेज के रूप में इंटीग्रेट किया गया है, और Axis Bank, जिसका API हर रिक्वेस्ट को AES-256-CBC (PBKDF2-derived key) और HMAC-SHA512 से साइन करने की मांग करता है, यह किसी JS क्रिप्टो लाइब्रेरी के बजाय एक हाथ से लिखे नेटिव Android मॉड्यूल (NdpsAESLibrary, जो NativeModules के ज़रिए JS में ब्रिज किया गया है) में किया गया है, क्योंकि पेमेंट गेटवे की साइनिंग ज़रूरत ऐसी चीज़ नहीं जिसे RN लेयर सामान्य तरीके से पूरा कर सके। Firebase auth और analytics दोनों संभालता है।
रिपोर्ट, सिर्फ़ एक टेबल नहीं
रिपोर्ट फ्लो डिलीवरी और बिज़नेस डेटा को Victory Native के ज़रिए चार्ट के रूप में रेंडर करता है, फिर उसी डेटा को CSV में एक्सपोर्ट करता है: json2csv से एनकोड किया गया, Android के Scoped Storage API (react-native-scoped-storage, जो Android 10+ पर ज़रूरी है जब से ऐप्स ने डायरेक्ट फाइलसिस्टम एक्सेस खोया) के ज़रिए डिस्क पर लिखा गया, और नेटिव शेयर शीट के ज़रिए आगे भेजा गया।
डेटा मॉडल और स्केल
- 13-14 अलग फ्लो कंटेनर (address, assets, business, delivery, home, location, order, pickup, reports, settings, support, user, wallet) ऐप के नेविगेशन को व्यवस्थित करते हैं, जो "14 यूज़र फ्लो" के आंकड़े से मेल खाता है।
- एक समर्पित नेटिव Android मॉड्यूल बैंक-ग्रेड रिक्वेस्ट साइनिंग का मालिक है; ऐप में बाकी सब कुछ React Native के ब्रिज के ऊपर JS/TypeScript में रहता है।
Stack
React Native, GraphQL Code Generator के साथ urql, स्टेट के लिए Zustand, स्टोरेज के लिए MMKV, वैलिडेशन के लिए Zod, react-native-maps, जियोस्पेशियल गणना के लिए Turf.js, पेमेंट के लिए Easebuzz और Axis Bank (बाद वाला एक कस्टम नेटिव AES/HMAC साइनिंग मॉड्यूल के पीछे), रिपोर्टिंग चार्ट के लिए Victory Native, auth और analytics के लिए Firebase, Hasura GraphQL पर।