Rails में फिर से लिखना
(dirkjonker.bearblog.dev)- कस्टम्स डिक्लेरेशन बनाने वाली application ने कई stacks की समीक्षा के बाद, परिचित Ruby on Rails को शुरुआती implementation के लिए चुना, क्योंकि नए विकल्पों की तुलना में इसमें features बनाना अनुभव के हिसाब से काफी तेज था
- Rust backend और SvelteKit frontend से बना “version 2” तेज और देखने में अच्छा था, लेकिन उसमें ज़रूरी features के करीब 10% ही थे, और business code से ज़्यादा plumbing work बढ़ गया
- क्रमिक migration में routing, data access, permissions, change tracking, search, background jobs, pub/sub, email, OAuth 2.0, SMTP/POP, object storage, PDF generation तक सब कुछ खुद जोड़ना पड़ रहा था, जिससे user value लगभग नहीं बढ़ी
- तय किया गया कि नए stack में migrate किए गए हिस्सों को ही वापस Rails में लाया जाए; अकेले Rails app maintain करने की स्थिति, user needs पूरी न कर पाने का stress, और कई जगहों पर साथ-साथ fixes करने की complexity ने फैसले को प्रभावित किया
- Rails पर लौटने के बाद feature development, मौजूदा features में सुधार, UI updates और bug fixes की रफ्तार फिर बढ़ी; Ruby/Rails की कमियों को testing, refactoring, Turbo और caching से handle करते हुए product development पर focus करने का रास्ता चुना गया
अस्थायी विकल्प के रूप में Rails चुनने की शुरुआत
- 2022 में कस्टम्स डिक्लेरेशन बनाने वाली application बनाना शुरू करते समय .NET/F#, Go, Rust, React जैसी कई languages और frameworks की समीक्षा की गई और सच में code लिखकर भी देखा गया
- अंतिम चुनाव Ruby on Rails था
- यह पहले से परिचित tool था, और नए सीखे जाने वाले विकल्पों की तुलना में अनुभव के हिसाब से लगभग 10 गुना तेजी से आगे बढ़ा सकता था
- उस समय Rails implementation एक अस्थायी proof of concept के करीब था, और आगे चलकर Ruby जैसी गलती करना आसान बना देने वाली language के बजाय किसी दूसरी language में फिर से लिखने की योजना थी
- Rails application ने तेजी से features बढ़ाए, और colleagues को भी output पसंद आया
- productivity बढ़ाने वाले features जल्दी बनाए जा सके
- शुरुआत में अक्सर आने वाली error situations को code से रोका जा सका
Rust और SvelteKit “version 2” कहां अटका
- “version 2” के लिए backend में Rust और frontend में SvelteKit चुना गया
- शुरुआती version देखने में अच्छा और तेजी से चलने वाला था, लेकिन उसमें ज़रूरी features के केवल करीब 10% ही मौजूद थे
- Rust में Rails से तुलना करने लायक integrated framework नहीं था, इसलिए business logic से ज्यादा foundational code और integration work लिखना पड़ रहा था
- यह साफ हो गया कि पूरा version 2 बनाने के लिए version 1 development को पूरी तरह रोकना पड़ेगा, और आखिरकार version 2 को छोड़ दिया गया
- यह पुष्टि हुई कि rewrite में उतना ही समय लग सकता है जितना original application को पहली बार बनाने में लगा था
क्रमिक migration से बनी operational complexity
- Rust की strong typing, तेज performance और compile successful होने पर मिलने वाले confidence की वजह से application में Rust लाने की इच्छा बनी रही
- Ruby को 4 साल से ज्यादा इस्तेमाल करने के बावजूद runtime issues लगातार आते रहे
- मुख्य समस्याएं null values और unhandled exceptions थीं
- deployment के बाद error reporting tool देखकर production issues को जल्दी ठीक किया जाता था
- Rails frontend में logic और markup का कई files में बिखरना खटकता था, जबकि Svelte में related logic को एक file में रखना आसान था
- योजना बनी कि नया frontend धीरे-धीरे SvelteKit में, नया backend Rust में लिखा जाए, और मौजूदा Rails हिस्सों को भी क्रमिक रूप से replace करके अंत में Rails हटाया जाए
- शुरुआत में records lists और filters वाली “index” pages को नए stack में ले जाने का काम तेजी से हुआ
- नया stack तेज चलता था और Rust हिस्से में runtime issues लगभग नहीं थे
- कौन-सा route Rails, Rust या SvelteKit पर जाना चाहिए, यह तय करने वाले deployment rules जटिल हो गए
- इस complexity को पूरे transition तक की अस्थायी स्थिति के रूप में स्वीकार किया गया
user value से बड़ा हुआ technical work
- समय के साथ Rails side में उपयोगी नए features लगातार जुड़ते रहे, और मौजूदा features भी अधिक गहरे और sophisticated होते गए
- शुरुआती गलत assumptions को ठीक करने के लिए कई refactorings की गईं, और माना गया कि अच्छी तरह design किया गया database schema किसी भी version में मददगार होगा
- Rails UI को जल्द replace होना है, ऐसा मानकर उस पर और ज्यादा समय न लगाने का फैसला किया गया
- कुछ महीनों बाद business इतना successful हुआ कि full-time developer hire किया जा सके, और उम्मीद थी कि Rust transition तेज होगा
- वास्तव में नए stack में काफी समय abstractions और mechanisms लिखने में गया
- database access
- यह सुनिश्चित करने के लिए permission handling कि users केवल वही data देखें जिसकी उन्हें अनुमति है
- हर change को track करना
- search और filters
- type system के जरिए constraints लागू करना
- इसके बाद ज़रूरी features की list भी लगातार बढ़ती गई
- background jobs
- client updates के लिए pub/sub system
- email functionality
- external services से connection के लिए OAuth 2.0
- SMTP और POP
- object storage
- PDF generation
- Rust libraries पर्याप्त थीं, लेकिन सही library चुनना और सबको जोड़ना बड़ा काम था
- Rust ORM selection, Svelte 5 release timing और improvements जैसे technical implementation details पर चर्चाएं बढ़ती गईं
- लगभग 1 साल Rust और Svelte लिखने के बाद यह साफ हो गया कि users को इस काम से लगभग कोई फायदा नहीं मिल रहा है
- नए stack की कुछ screens smooth और fast थीं, लेकिन वे original problem areas नहीं थीं
- सबसे ज्यादा इस्तेमाल होने वाली pages अभी भी Rails पर चलती थीं, और नए stack के “beta version” से 10 गुना ज्यादा features रखती थीं
- कई दिन या कई हफ्ते ऐसे कामों में लग जाते थे जो सीधे कोई value नहीं जोड़ते थे
Rails पर वापस लौटने का फैसला
- तय किया गया कि नए stack पर चल रहे हिस्सों को ही Rails में फिर से लिखा जाए
- यह पूरी application को फिर से लिखना नहीं था, बल्कि Rust/SvelteKit में migrate किए गए हिस्सों को Rails में वापस लाने का चुनाव था
- फैसला कठिन था, लेकिन तार्किक था
- पहले ही काफी समय और code invest किया जा चुका था
- संभव था कि team members Ruby या Rails पसंद न करें
- अच्छी बात यह रही कि team ने फैसला समझा और नया सीखने के लिए तैयार थी
- Rails की ताकत यह है कि बहुत-सी functionality default रूप से शामिल है, mature और stable libraries का ecosystem है, और conventions व opinionated design की वजह से code concise रहता है
- Rails product बनाने पर focus करने देता है और lower-level support code खुद लिखने का बोझ कम करता है
Rails पर लौटने के बाद बचे lessons
- Rust और Svelte का प्रयास पूरी तरह बेकार नहीं था
- नई languages और frameworks सीखते हुए ऐसे insights और ideas मिले जो दूसरी languages में भी मददगार हैं
- web application लिखना लगातार choices और trade-offs का सिलसिला है
- framework की कमियों को स्वीकार करना पड़ता है या खुद implementation में invest करना पड़ता है, और यह देखना पड़ता है कि वह investment competitive advantage और long-term rewards देगा या नहीं
- Rails में वापस लाने का काम काफी हद तक सरल था और stress भी कम हुआ
- पिछले कुछ हफ्तों में new feature development, existing feature improvements, UI updates और bug fixes में फिर से productivity महसूस होने लगी
- Ruby और Rails की कमियों को code लिखते समय ध्यान में रखने वाली conditions के रूप में स्वीकार किया गया
- runtime issues ज्यादा हों तो testing ज्यादा करनी होगी
- maintain करना मुश्किल spaghetti code, language या framework से ज्यादा developers के कारण आसानी से बनता है
- refactoring और code organization पर ज्यादा समय लगाना होगा
- अगर Rails को scale करना मुश्किल है, तो माना गया कि दूसरी चीजों को scale करना भी मुश्किल होगा
- Rails पर्याप्त तेज है, और Turbo व caching से bypass करने के तरीके मौजूद हैं
- user के नजरिए से Rust stack noticeable रूप से ज्यादा fast नहीं था
- Rails में सबसे भारी page की P95 duration 338ms है; सुधार की गुंजाइश है, लेकिन यह इतना तेज महसूस होता है कि पर्याप्त है
- कोई perfect language या framework नहीं होता; उनकी strengths और weaknesses समझकर उन्हें handle करने का तरीका चाहिए
- जो लोग अच्छा product बनाने पर focus करना चाहते हैं, उनके लिए Rails बहुत अच्छे frameworks में से एक है, और लंबे समय से maintained व active contributors वाले दूसरे frameworks भी इसी तरह अच्छे विकल्प हो सकते हैं
2 टिप्पणियां
Ruby में फिर से लिखें
Rails में फिर से लिखें
Hacker News टिप्पणियाँ
मेरा मानना है कि वेब ऐप बनाते समय Rails, Django और Laravel समेत, दूसरे स्टैक्स से काफी आगे है
इसने बोरिंग हिस्सों को पहले ही संभाल लिया है, ज़रूरी आवश्यकताओं को जानता है, और असली ऐप बनाते समय कम अड़चन पैदा करता है। 15 साल तक वेब ऐप्स बनाते हुए मैंने Meteor, Remix, Next.js, Express-आधारित Node.js आदि इस्तेमाल किए हैं, लेकिन वेब डेवलपमेंट अब काफी हद तक हल की हुई समस्या जैसा लगता है। JavaScript की दुनिया बड़े कॉरपोरेट फंडिंग के असर से डेवलपर्स के लिए नए खिलौनों से खेलने जैसी ज़्यादा लगती है, और Rust या Go सिस्टम डेवलपमेंट व डिप्लॉयमेंट इन्फ्रास्ट्रक्चर के लिए अच्छे हैं, लेकिन उन्हें ज़बरदस्ती वेब डेवलपमेंट में ठूँसना समझ में नहीं आता
यह अनगिनत Java लाइब्रेरीज़ के साथ आसानी से इंटीग्रेट हो जाता है, और static typed language होने के कारण कई स्थितियों में मददगार है। Jackson के जरिए convention-based data binding भी बहुत पहले से शानदार रही है, जबकि dynamic typed languages में यह चीज़ बाद में जोड़ी गई लगती है
लेकिन Rails, Django, Laravel में गहराई तक जाने के बाद अगर conventions से हटकर कुछ करना पड़े तो मुश्किल हो सकता है। चूँकि glue code आपने खुद नहीं लिखा होता, इसलिए तकनीकी रुकावट से ज़्यादा समझ की कमी वाली स्थिति बनती है। फिर भी अगर अंदरूनी हिस्सों को ठीक से सीख लिया जाए, तो सिर्फ कोड पढ़कर ही बहुत सारा कोडिंग समय बचाया जा सकता है। बेशक, असल में ऐसा नहीं करते, क्योंकि सब कुछ फिर से लिखना इतना मज़ेदार होता है कि बिज़नेस के हिसाब से सही न होने पर भी नई कोशिशें करने का मन करता है
सिर्फ मेरी राय पर मत जाइए, डेटा देख लीजिए: https://www.youtube.com/watch?v=Qp9SOOtgmS4
अगर ऐसे सर्विस के लिए Rails चुना जाए जहाँ users की संख्या या requests per second का भरोसेमंद अंदाज़ा न हो, तो लॉन्च के समय लागत तो बच सकती है, लेकिन बाद में सर्वर लागत ज़्यादा देनी पड़ सकती है
Rails डेमो में मुझे खास आकर्षण नहीं लगा; उसने बस यह दिखाया कि adoption और attention पाने में किस्मत कितनी अहम होती है। आज भी इसकी वैल्यू मुझे पूरी तरह समझ नहीं आती, और मैं Spring या ASP.NET चुनूँगा। उस Tcl-आधारित startup के founders ने बाद में OutSystems बनाया, जो enterprise-scale वेब डेवलपमेंट में सफल कुछ गिने-चुने RAD tools में से एक है और पुर्तगाल के IT उद्योग की सफल कहानियों में शामिल है
पहले मुझे Rails ज़्यादा पसंद था, लेकिन पिछले 10 से अधिक वर्षों में Python के तेज़ी से बढ़ने के कारण Django ज़्यादा व्यावहारिक विकल्प बन गया है। machine learning और data science डेवलपर्स पहले से ही Python से परिचित होते हैं, और Django का documentation इतना अच्छा है कि ज़रूरत पड़ने पर बहुत कम समय में productivity लाई जा सकती है। मैंने यह कई प्रोजेक्ट्स में खुद देखा है
Django, कम opinionated libraries या microframeworks की तुलना में, application structure को लेकर होने वाले फैसले और बहस भी कम कर देता है। Django/FLOSS community भी उम्मीद से कहीं ज़्यादा सक्रिय है, और उसके साथ बातचीत सुखद रही है। बस, काश Rails जैसे generators और built-in data seeding, जैसे
rake db:seed, जैसी सुविधाएँ इसमें भी होतींमैं 17 साल से Rails इस्तेमाल कर रहा हूँ, अब भी पसंद करता हूँ, और frontend में भी इसे तरजीह देता हूँ
यह कोड को अलग-अलग रखने के सारे विकल्प देता है, बिना इस समस्या के कि फ़ाइल का ऊपर वाला हिस्सा Angular ऐप्स की तरह बेवजह लंबी
includesसूची बन जाए। मुझे frontend में logic और markup को अलग करने में कोई कमी नहीं लगती। logic को स्वतंत्र रूप से test किया जा सकता है, और आम तौर पर bug ढूँढते समय यह पता चल जाता है कि समस्या markup में है या logic में, इसलिए tracing आसान हो जाती है। मैंने 200 लाइनों से लंबे Ruby methods भी काफी लिखे हैं, लेकिन वह पूरी तरह मेरी गलती थी, और अगर ज़्यादा बारीक unit test व्यवस्था होती तो इसे रोका जा सकता थाincludesसूची से बचने का एक और तरीका है कि सब कुछ global बना दिया जाएयह फायदा है या नहीं, इस पर मुझे यक़ीन नहीं। imports जगह ज़रूर घेर सकते हैं, लेकिन वे यह साफ-साफ दिखाते हैं कि सब कुछ कैसे जुड़ा हुआ है। अगर यह परेशान करे, तो IDE में fold कर दीजिए
यह लेख यथार्थवादी लगा और अच्छा लगा। इसका मुख्य वाक्य हमेशा पास रखकर देखने लायक है
“दिलचस्प बात यह है कि Ruby और Rails में जो चीज़ें पहले मुझे परेशान करती थीं, अब वे उतनी खटकती नहीं हैं। मैंने यह मान लिया है कि कोई भी भाषा या framework परफ़ेक्ट नहीं होता। उसकी ताकत और कमज़ोरियाँ जानकर उनके साथ काम करना ही होता है”
कई बार उन्होंने framework को ठीक से समझा ही नहीं होता, और यह भी नहीं जानते कि चीज़ें वैसी क्यों हैं। लेकिन सीमाएँ समझकर framework के साथ काम करना कहीं ज़्यादा असरदार होता है। जो tools आप इस्तेमाल करते हैं, उन्हें सही मायने में समझने पर समय देना चाहिए
“इस दौरान मैंने application का ‘version 2’ बनाना शुरू किया। backend language के लिए Rust चुनी, और frontend के लिए SvelteKit।”
चूँकि v1 की शुरुआत Rails से हुई थी, यह ऐसे पढ़ा जाता है जैसे पहले से अच्छे से काम कर रहे framework को छोड़ते समय सावधान रहना चाहिए
Rust बहुत होशियार लोगों द्वारा बनाई गई भाषा है, लेकिन लगता है कि इसका फ़ोकस मेरे जैसे प्रैक्टिकल डेवलपर के लिए उपयोगी और सुसंगत चीज़ें बनाने से ज़्यादा type theory और कुछ allocations बचाने पर है
मैं 2020 से Rust इस्तेमाल कर रहा हूँ, फिर भी Rust के ब्लॉग पोस्ट पढ़ते समय उनका सचमुच आधा हिस्सा समझ नहीं पाता
खासकर बड़े mainstream भाषाओं से तुलना करें तो। उदाहरण के लिए trait, C++ के abstract class और concepts, तथा Python के abstract class और protocol के use cases—सबको समेट लेता है। exception इस्तेमाल करना है या value return करके error handle करना है, ऐसी कोई असंगति भी नहीं है। panic है, लेकिन वह assertion की तरह इस्तेमाल होता है। अगर
if-elseexpression है, तो अलग ternary operator की भी ज़रूरत नहीं पड़तीहाल में Rust को हर चीज़ के लिए इस्तेमाल करने का एक ट्रेंड है, लेकिन यह CRUD apps के लिए बनाई गई भाषा नहीं है। आखिरकार यह लेख ज़्यादा एक case study जैसा है: “काम के लिए सही tool इस्तेमाल करो। अपने spare time में पसंद आने वाली भाषा या latest trendy भाषा ज़रूरी नहीं कि उसके लिए सही हो”
अगर आप garbage collector का खर्च उठा सकते हैं, तो Rust या C++ चुनकर memory management की चिंता करने की ज़रूरत नहीं है। कुछ लोग Rust को general-purpose programming language के रूप में promote करते हैं, और सिद्धांततः यह सही भी है, लेकिन 90s में C++ को भी ऐसे ही promote किया गया था। memory allocation को minimize करना अक्सर वही गुण है जिसकी आप Rust या C++ चुनते समय तलाश करते हैं
Rust में बड़ा web application जल्दी लिखना मुश्किल है
Rails में लिखा गया बड़ा application तेज़ न चल सकता है, उसमें bugs ज़्यादा हो सकते हैं, या उसे maintain और scale करना कठिन हो सकता है। Java, C#, Go जैसे विकल्प sexy या cool न लगें, लेकिन वे Rails जितनी तेज़ी से काम पूरा कर सकते हैं और Rust के काफ़ी करीब की गति से चल सकते हैं। आम तौर पर bugs भी कम होते हैं, और project को maintain व scale करना आसान होता है
Rails आपको जितना भी नापसंद हो, यह वैसा है जैसे कहना कि आप C++ में WordPress से भी जल्दी blog बना सकते हैं
ध्यान से बनाया जाए तो यह ज़रूरी नहीं है। मैंने बहुत से बड़े Rails apps देखे हैं जो लगभग bug-free, stable और बदलने में आसान थे, और बिखरे हुए Rails apps और Go apps भी देखे हैं। कुछ भाषाएँ या frameworks ऐसी स्थिति में पहुँचना आसान बना सकते हैं, लेकिन किसी भी चीज़ में ऐसी संभावना होती है, और दूसरी वजहों से मुश्किल होने वाले trade-offs भी होते हैं। अनुशासन हो तो किसी भी चीज़ को कामयाब बनाया जा सकता है
लगभग समान कौशल वाले डेवलपर्स के बीच, ज़्यादातर web application features में Rails, Java, C#, Go से तेज़ development देता है। मेरे अनुभव में यह 3 गुना तक तेज़ रहा है। मैंने बड़े monoliths और service-oriented architecture दोनों पर काम किया है और Java teams के साथ भी काम किया है। एक समय मैं भी इसी विश्वास के साथ Rails organization में Go लाया था
आखिर में असली समस्या यह थी कि MVC हर चीज़ के लिए फिट नहीं बैठता, और namespaces का इस्तेमाल पर्याप्त सख़्ती से नहीं किया गया था। छोटे, targeted क्षेत्रों में उस समस्या को ठीक कर दिया जाए तो Rails काफ़ी अच्छा है
इसलिए पर्याप्त management, अच्छी architecture और maintenance हो तो Rails में भी यह संभव है
हाल में मैंने Rails के TypeScript विकल्प के रूप में AdonisJS को test करना शुरू किया है
अगर आपकी रुचि “TypeScript में Rails” जैसी चीज़ में है, तो इसे एक बार आज़माने की सलाह दूँगा। यह सबसे लोकप्रिय TypeScript stacks की तुलना में Rails या Laravel के कहीं ज़्यादा करीब महसूस होता है, और stack के हर हिस्से को खुद चुनने या third-party templates पर भरोसा करने के बजाय batteries-included तरीका अपनाता है
हाल में मैं Rails, Laravel, Django जैसे batteries-included backend frameworks की ओर आकर्षित हो रहा हूँ, लेकिन मैंने अपने पूरे career में लगभग सिर्फ TypeScript ही इस्तेमाल किया है, इसलिए अभी बदलने से आसान वही लगता है। आपने test करके कैसा पाया, और क्या आप इसे यहाँ बताए गए दूसरे frameworks से compare कर सकते हैं—यह जानना चाहूँगा
हाल के personal project में मैंने NestJS चुना था, लेकिन उसके तुरंत बाद Adonis के बारे में पता चला, और अब सच में switch करने पर विचार कर रहा हूँ
Next.js और SvelteKit जैसी technologies JavaScript developers के बीच इसलिए लोकप्रिय हैं क्योंकि वे Node.js के backend development experience के खराब हिस्सों को कुछ हद तक कम करती हैं
TypeScript में backend बनाना C# में बनाने जैसा लगता है, लेकिन उसमें एक properly designed language के फायदे गायब लगते हैं। यह Rails में backend बनाने के अनुभव से काफ़ी अलग है। Node.js developers भी समझने लगे हैं कि समस्या सिर्फ ecosystem और tooling की नहीं है; ऐसा framework अहम है जो application बनाने का एक समग्र समाधान दे। Next.js और SvelteKit इसी जगह मदद करते हैं, और Rails ने 2006 में इसी बात पर क्रांति लाई थी
क्या सिर्फ backend में code चलाने की क्षमता की तुलना Rails से की जा रही है? database access, migrations, ORM, queue, scheduled jobs, validation, translation, authentication, authorization support कहाँ है? Next.js जिस एक चीज़ में मदद करता है, वह लोगों को Vercel platform की ओर धकेलना है
frontend के लिए, JavaScript की तुलना में TypeScript को पसंद करूँगा
वे टिप्पणियाँ कि Rust वेब बैकएंड के लिए खास अच्छा नहीं है, मुझे थोड़ा उलझाने वाली लगती हैं
beampaint.com या probablyup.net जैसी छोटी सेवाएँ बनाते हुए मेरा अनुभव इसके उलट रहा है। बड़े ऐप बनाते समय जटिलता काफ़ी बढ़ सकती है, और शायद निश्चित रूप से बढ़ेगी, लेकिन बड़े codebase में ज़रूरी आत्मविश्वास देने में Rust बेहतरीन है
पुराने frameworks में ये चीज़ें डिफ़ॉल्ट रूप से होती हैं, लेकिन Rust frameworks के साथ उनकी कम उम्र की वजह से ऐसा होने की संभावना कम है। बस कल्पना कीजिए कि missing features दो से बढ़कर छह हो जाएँ
यह लेख लगभग मेरी अपनी जीवन-कहानी जैसा है
Rails इस्तेमाल करने के बाद मैंने 2013 में Go में लिखा हुआ एक SaaS app लॉन्च किया था, और हर चीज़ खुद समझनी पड़ी। migrations, database layer, asset pipeline, deployment, validation, logging, payments वगैरह—Rails ऐसी बहुत-सी चीज़ें बस दे देता था
मुझे Go पसंद नहीं है, लेकिन यहाँ दोष Go का नहीं है। CRUD applications के लिए Go का इस्तेमाल करना शुरू से ही एक भयानक फ़ैसला है
Django के साथ भी कुछ ऐसा ही महसूस होता है
performance समस्याएँ Django की वजह से कम, और database queries की वजह से कहीं ज़्यादा होती थीं
अक्सर भूल जाने वाली आसान optimizations में database indexes बनाना, code की बजाय database को ज़्यादा logic सौंपना—जैसे MongoDB pipelines या Postgres partial indexes का इस्तेमाल—ज़्यादातर requests पर Brotli/zstd compression चालू करना, Redis जैसे memory cache से objects या requests को cache करना, और सही cache-control headers सेट करना शामिल है। frontend में भी हज़ारों objects को DOM nodes के रूप में render करने के बजाय canvas का इस्तेमाल करने जैसी optimization की ज़रूरत होती है। मैंने हाल ही में एक map application में ऐसी समस्या देखी थी