स्टार्टअप के लिए फायरस्टोर का इस्तेमाल न करें

Feb 10 2022

संक्षेप में, यह शीर्षक के रूप में है। दो मुख्य कारण हैं कि मैं फायरस्टोर की अनुशंसा क्यों नहीं करता। ऐसा लगता है कि बहुत से लोग नहीं जानते कि स्कीमा न होने का क्या मतलब है। यदि आपके ऐप को वास्तव में स्कीमा की आवश्यकता नहीं है, तो फायरस्टोर एक अच्छा विकल्प है। लेकिन क्या ऐसा कुछ है? उदाहरण के लिए, निम्न समस्याएँ उत्पन्न होती हैं। मान लीजिए कि आप उपयोगकर्ता के लिए एक मॉडल बनाते समय आयु नामक फ़ील्ड तैयार करते हैं। चूंकि यह एक उम्र है, आइए एक पूर्णांक प्रकार का उपयोग करें। हालांकि, चूंकि कोई स्कीमा नहीं है, आप किसी संख्या के बजाय "37" जैसे वर्ण स्ट्रिंग डाल सकते हैं। सभी लोअरकेस अक्षरों में फ़ील्ड और मान के साथ फ़ील्ड नाम को गलती से उम्र के रूप में निर्दिष्ट करना भी संभव है। किसी भी डेटा को तब तक दर्ज या परिभाषित किया जा सकता है जब तक वह स्कीमा रहित हो। कुछ लोग आशावादी हो सकते हैं कि इस तरह की बेवकूफी नहीं होगी, लेकिन मैंने सुना है कि किसी कारण से पुष्टि_पासवर्ड वास्तव में दर्ज किया गया था, और यह कि पासवर्ड अनजाने में सादे पाठ में डीबी में मिश्रित हो गया था। कभी-कभी। यदि आपने एक स्कीमा परिभाषित किया है, तो आप ऐसी गलतियाँ नहीं कर सकते। आखिरकार, मैं ऐसी गलतियों को रोकने के लिए ओरियोल फ्रेमवर्क जैसा कुछ लिखता हूं। वहां एक मॉडल परिभाषित किया गया है, और आप केवल अपने द्वारा लिखे गए ढांचे का उपयोग करके डेटा सम्मिलित और अपडेट कर सकते हैं। हालांकि, अगर आप इसके बारे में ध्यान से सोचते हैं, हालांकि यह एक ऐसी सेवा थी जो स्कीमालेस बंजई के साथ शुरू हुई थी, आपके पास ढांचे के पक्ष में स्कीमा को परिभाषित करने और संचालित करने के अलावा कोई विकल्प नहीं है। फिर, शायद आप शुरुआत से एक स्कीमा के साथ एक डीबी का उपयोग कर सकते हैं। इसके अलावा, oleore ढांचे के भीतर, बनाएँ, अपडेट आदि को सीधे लिखना आवश्यक है। यह कब होगा? जब मैं PHP में कच्चा SQL कोड लिख रहा था, तब से यह अलग नहीं है। रेल और डीजेगो में ओआरएम हैं, और अब मैं सीधे एसक्यूएल स्टेटमेंट नहीं लिखता हूं। प्रत्यक्ष लेखन छोटा, समय लेने वाला और खतरनाक है। यह एकमात्र स्कीमालेस समस्या नहीं है। जटिलता के कारण विकास कठिन है। ग्राहक और इंजीनियर की इच्छा के कारण शुरू में सरल ऐप अधिक जटिल होते जा रहे हैं। इसलिए, किसी बिंदु पर किसी के लिए एक स्कीमा परिभाषित करना आवश्यक हो जाता है। यह अच्छा होगा यदि स्कीमा जानकारी (मॉडल जानकारी) को कहीं केंद्रीय रूप से प्रबंधित किया गया हो, लेकिन यह काम नहीं करता है। बिना (भले ही) स्कीमा, Android, जब आप आईओएस, वेब डेवलपमेंट इत्यादि में प्रत्येक फ्रेमवर्क का उपयोग करना शुरू करते हैं, तो यह अराजकता बनने लगती है। एक समस्या यह भी है कि यदि आप किसी अन्य प्लेटफॉर्म से गलत डेटा पुश करते हैं, तो यह दूसरे प्लेटफॉर्म पर क्रैश हो जाएगा। फिर, ऐसा नियम क्यों नहीं बनाया जाए जो केवल एक सर्वर के माध्यम से केवल एपीआई एक्सेस को प्रोसेस करता हो? होगा। हालांकि, उदाहरण के लिए, फायरस्टोर की महान (और केवल मुझे लगता है) सुविधाओं में से एक, रीयल-टाइम चैट को आसानी से कार्यान्वित करने की क्षमता है, जो क्लाइंट साइड और फायरस्टोर के बीच सीधे संचार के लिए एक तंत्र है। चूंकि फायरबेस के साथ सीधे संवाद करना आवश्यक है, इसलिए सामने बनाए गए सर्वर के माध्यम से जाना संभव नहीं है, इसलिए आपको क्लाइंट साइड पर डीबी मॉडल और नियंत्रक लिखना होगा। यदि आप नियम निर्धारित करते हैं कि केवल एक सर्वर है, तो आप इन सुविधाजनक कार्यों का उपयोग नहीं कर पाएंगे। (यह एक स्कीमालेस डीबी है!) मुझे स्कीमा का प्रबंधन कैसे करना चाहिए? एक साझा फ़ोल्डर में एक पाठ फ़ाइल? धारणा? Google ड्राइव? कोई इसे छूता है? क्या यह सुसंगत है? क्या होगा अगर विवरण में कोई चूक है? क्या टीम के सभी सदस्यों के लिए इसके महत्व को समझना और बिना गलतियों के मॉडल को ठीक से परिभाषित और प्रबंधित करने के लिए एक प्रणाली बनाना और संचालित करना संभव है? ये चिंताएँ एक के बाद एक होती हैं, और टीम के भीतर अनावश्यक परामर्श और आदान-प्रदान बढ़ता है। आखिरकार, विकास दक्षता बहुत खराब हो जाती है। 2. अन्य कमबख्त समस्याएँ Firestore वहाँ नहीं रुकता। खोज बहुत खराब है। एकत्र करना बहुत कठिन है। फायरस्टोर में व्हेयर सर्च नाम का एक फंक्शन है जो आपको शर्तों के अनुसार सर्च करने की अनुमति देता है। उदाहरण के लिए, आप उन उपयोगकर्ताओं की सूची प्राप्त कर सकते हैं जिनकी आयु 37 वर्ष या उससे अधिक है। हालांकि, प्रतिबंध हैं, और दो या दो से अधिक असमानता के संकेतों की खोज करना संभव नहीं है। दूसरे शब्दों में, 10 वर्ष से अधिक और 20 वर्ष से कम आयु के लोगों को निकालना संभव नहीं है। आपके पास जितने अधिक मॉडल होंगे, आपको उतनी ही अधिक चिंता करनी होगी। इसलिए, अनावश्यक फ़ील्ड जोड़े जाते हैं और संग्रह जोड़े जाते हैं। ओलेओर फ्रेमवर्क का मॉडल हर बार अपडेट किया जाता है, और सिस्टम अधिक से अधिक गंदा हो जाता है। यह भी एक बड़ी समस्या है कि आप संबंध नहीं बना सकते। नहीं, ऐसे लोग हैं जो इसे चिपका सकते हैं। निश्चित रूप से एक DocReference प्रकार है। हालांकि, Django या Rails जैसे ढांचे का उपयोग किए बिना संबंधों को चिपकाने का कार्य बेहद खतरनाक है। यह एक आत्मघाती कृत्य है। उदाहरण के लिए, आप कैसे पता लगाते हैं कि जब वस्तु का बिंदु मिट जाता है? बेशक मैं जवाब नहीं दे सकता। इसलिए, ओलेओर ढांचे को मिटाते समय व्यवहार और प्रबंधन फ़ंक्शन बनाना आवश्यक है। कौन? इसे कौन विकसित करेगा? यह आप है। सबसे पहले, फायरस्टोर के लिए डीबी में डुबकी लगाना आदर्श है क्योंकि यह इसे सामान्य किए बिना है। यदि आप संबंधों को चिपकाने जैसे सामान्य करना चाहते हैं, तो आपको स्कीमालेस का उपयोग करने की आवश्यकता नहीं है, और आपको संबंधपरक डीबी पर विचार करना चाहिए। मैं दस्तावेज़-आधारित डेटाबेस में संबंधों को चिपकाने के बारे में नहीं सोचना चाहता हूं। मैं आपको आश्वस्त कर सकता हूं, लेकिन एक दिन मुझे कई से कई टेबल की याद आती है और मैं मर रहा हूं। उस समय तक, आपको पछताना शुरू हो जाना चाहिए कि आपने फायरस्टोर को क्यों चुना। Firestore के बारे में एक बुरी बात यह है कि इसका बैकअप लेना बहुत मुश्किल है। प्रोडक्शन से स्टेजिंग तक कॉपी करना आसान नहीं है, इसलिए बोलना है। यह विकास दक्षता को भी बहुत खराब बनाता है। कभी-कभी जब कोई सुविधा पूर्ण हो जाती है और आप एक परीक्षण चलाना चाहते हैं, तो आप उत्पादन से डेटा खींचना चाहते हैं (हालांकि यह वास्तव में अच्छा नहीं है) और इसे जांचें (दूसरी बार, लेकिन यह वास्तव में अच्छा नहीं है)। फायरबेस ऐसा नहीं कर सकता। क्योंकि उपयोगकर्ता डेटा माइग्रेट करना आसान नहीं है। जब ऐप का आकार उचित होता है, तो उपयोगकर्ता और फायरस्टोर कुछ (ज्यादातर यूआईडी) से जुड़े होते हैं, लेकिन चूंकि यह उपयोगकर्ता समूह को नहीं खींचता है, इसलिए उत्पादन वातावरण के डेटा का परीक्षण और पुष्टि करना बहुत मुश्किल है। यहां तक कि फायरस्टोर का माइग्रेशन भी मुश्किल है क्योंकि यह मैनेजमेंट स्क्रीन पर पॉप हो रहा है। आप सोच सकते हैं कि आपको फायरबेस लोकल एमुलेटर सूट का उपयोग करना चाहिए, लेकिन यह एक बहुत बड़ा अनुभव है, इसलिए इसे आजमाएं। अंत में, फायरबेस ने इसे एक बार किया है, लेकिन यह आखिरी है। ऐसा इसलिए है क्योंकि प्रमाणीकरण भाग को दूसरे में स्थानांतरित करना आसान नहीं होगा क्योंकि यह उपयोगकर्ता द्वारा उपयोग किया जाता है। इसलिए मैंने यह लेख यह सोचकर लिखा है कि जब स्टार्टअप पहली बार फायरस्टोर चुनते हैं तो उन्हें पारलौकिक पछतावे से मरना चाहिए। Firestore के साथ, मेरे पास इसके बारे में सोचने के लिए बहुत समय है। क्या करना है इसके बारे में बात करना पूरी तरह से बकवास है क्योंकि आप इसे नहीं कर सकते हैं, ट्विस्ट और टर्न का स्रोत कोड लिखें, अनावश्यक फ़ील्ड जोड़ें और परीक्षण करें, और विभिन्न चीजों की जांच करें। आपके पास कितना भी विकास समय क्यों न हो, यह पर्याप्त नहीं है। फायरबेस निवेशकों के लिए सरल ऐप बनाने, प्रस्तुत करने, सेवाओं को आज़माने और अति-छोटी सेवाओं के लिए बहुत अच्छा है। यह उन इंजीनियरों के लिए भी उपयुक्त है जो रिलेशनल डेटाबेस से परिचित नहीं हैं। कुछ मेरी कहानी के खिलाफ बहस करेंगे। यह एप्लिकेशन, विकास विधि और आकार पर निर्भर करता है, बैकअप विधि ऐसा नहीं है, इस विधि से संबंध हल किया जा सकता है, स्केलेबिलिटी उत्कृष्ट है, आदि। मैं इसे सुनना नहीं चाहता, और मैं केवल उस फायरस्टोर का उपयोग करना चाहता हूं जो मुझे पसंद है। ..

संक्षेप में, यह शीर्षक के रूप में है। दो मुख्य कारण हैं कि मैं फायरस्टोर की अनुशंसा क्यों नहीं करता।

स्कीमा के बिना समस्या
अन्य कमबख्त समस्याएं

ऐसा लगता है कि बहुत से लोग नहीं जानते कि स्कीमा न होने का क्या मतलब है।

यदि आपके ऐप को वास्तव में स्कीमा की आवश्यकता नहीं है, तो फायरस्टोर एक अच्छा विकल्प है। लेकिन क्या ऐसा कुछ है?

उदाहरण के लिए, निम्न समस्याएँ उत्पन्न होती हैं। मान लीजिए कि आप उपयोगकर्ता के लिए एक मॉडल बनाते समय आयु नामक फ़ील्ड तैयार करते हैं। चूंकि यह एक उम्र है, आइए एक पूर्णांक प्रकार का उपयोग करें। हालांकि, चूंकि कोई स्कीमा नहीं है, आप संख्या के बजाय "37" जैसे वर्ण स्ट्रिंग डाल सकते हैं । सभी लोअरकेस अक्षरों में फ़ील्ड और मान के साथ फ़ील्ड नाम को उम्र के रूप में गलती से निर्दिष्ट करना भी संभव है । किसी भी डेटा को तब तक दर्ज या परिभाषित किया जा सकता है जब तक वह स्कीमा रहित हो।

कुछ लोग आशावादी हो सकते हैं कि इस तरह की बेवकूफी नहीं होगी, लेकिन मैंने सुना है कि पुष्टि_पासवर्ड वास्तव में किसी कारण से दर्ज किया गया था, और यह कि पासवर्ड अनजाने में सादे पाठ में डीबी में मिश्रित हो गया था यदि आपने एक स्कीमा परिभाषित किया है, तो आप ऐसी गलतियाँ नहीं कर सकते।

आखिरकार , मैं ऐसी गलतियों को रोकने के लिए ओरियोल फ्रेमवर्क जैसा कुछ लिखता हूं । वहां एक मॉडल परिभाषित किया गया है, और आप केवल अपने द्वारा लिखे गए ढांचे का उपयोग करके डेटा सम्मिलित और अपडेट कर सकते हैं। हालांकि, अगर आप इसके बारे में ध्यान से सोचते हैं, हालांकि यह एक ऐसी सेवा थी जो स्कीमालेस बंजई के साथ शुरू हुई थी, आपके पास ढांचे के पक्ष में स्कीमा को परिभाषित करने और संचालित करने के अलावा कोई विकल्प नहीं है। फिर, शायद आप शुरुआत से एक स्कीमा के साथ एक डीबी का उपयोग कर सकते हैं।

साथ ही, oleore Framework में create, update आदि को सीधे लिखना आवश्यक है। यह कब होगा? जब मैं PHP में रॉ SQL कोड लिख रहा था, तब से यह अलग नहीं है ।

रेल और डीजेगो में ओआरएम हैं, और अब मैं सीधे एसक्यूएल स्टेटमेंट नहीं लिखता हूं। प्रत्यक्ष लेखन छोटा, समय लेने वाला और खतरनाक है।

यह एकमात्र स्कीमालेस समस्या नहीं है। जटिलता के कारण विकास कठिन है । ग्राहक और इंजीनियर की इच्छा के कारण शुरू में सरल ऐप अधिक जटिल होते जा रहे हैं। इसलिए, किसी बिंदु पर किसी के लिए एक स्कीमा परिभाषित करना आवश्यक हो जाता है । यह अच्छा होगा यदि स्कीमा जानकारी (मॉडल जानकारी) को कहीं केंद्रीय रूप से प्रबंधित किया गया हो, लेकिन यह काम नहीं करता है।

एक स्कीमा के बिना (भले ही यह हो), जब आप एंड्रॉइड, आईओएस, वेब डेवलपमेंट आदि पर प्रत्येक फ्रेमवर्क का उपयोग करना शुरू करते हैं तो यह अराजकता बनने लगती है। एक समस्या यह भी है कि यदि आप किसी अन्य प्लेटफॉर्म से गलत डेटा पुश करते हैं, तो यह दूसरे प्लेटफॉर्म पर क्रैश हो जाएगा।

फिर, ऐसा नियम क्यों नहीं बनाया जाए जो केवल एक सर्वर के माध्यम से केवल एपीआई एक्सेस को प्रोसेस करता हो? होगा। हालांकि, उदाहरण के लिए, फायरस्टोर की महान (और केवल मुझे लगता है) सुविधाओं में से एक, रीयल-टाइम चैट को आसानी से कार्यान्वित करने की क्षमता है, जो क्लाइंट साइड और फायरस्टोर के बीच सीधे संचार के लिए एक तंत्र है। चूंकि फायरबेस के साथ सीधे संवाद करना आवश्यक है, इसलिए सामने बनाए गए सर्वर के माध्यम से जाना संभव नहीं है, इसलिए आपको क्लाइंट साइड पर डीबी मॉडल और नियंत्रक लिखना होगा। यदि आप नियम निर्धारित करते हैं कि केवल एक सर्वर है, तो आप इन सुविधाजनक कार्यों का उपयोग नहीं कर पाएंगे।

(यह एक स्कीमालेस डीबी है!) मुझे स्कीमा का प्रबंधन कैसे करना चाहिए? एक साझा फ़ोल्डर में एक पाठ फ़ाइल? धारणा? Google ड्राइव? कोई इसे छूता है? क्या यह सुसंगत है? क्या होगा अगर विवरण में कोई चूक है? क्या टीम के सभी सदस्यों के लिए इसके महत्व को समझना और बिना गलतियों के मॉडल को ठीक से परिभाषित और प्रबंधित करने के लिए एक प्रणाली बनाना और संचालित करना संभव है?

ये चिंताएँ एक के बाद एक होती हैं, और टीम के भीतर अनावश्यक परामर्श और आदान-प्रदान बढ़ता है। आखिरकार, विकास दक्षता बहुत खराब हो जाती है।

2. अन्य कमबख्त समस्याएं

फायरस्टोर यहीं नहीं रुकता।

खोज बहुत खराब है । एकत्र करना बहुत कठिन है।

फायरस्टोर में व्हेयर सर्च नाम का एक फंक्शन है जो आपको शर्तों के अनुसार सर्च करने की अनुमति देता है। उदाहरण के लिए, आप उन उपयोगकर्ताओं की सूची प्राप्त कर सकते हैं जिनकी आयु 37 वर्ष या उससे अधिक है। हालांकि, प्रतिबंध हैं, और एक से अधिक असमानता चिह्न की खोज करना संभव नहीं है। दूसरे शब्दों में, 10 वर्ष से अधिक और 20 वर्ष से कम आयु के लोगों को निकालना संभव नहीं है । आपके पास जितने अधिक मॉडल होंगे, आपको उतनी ही अधिक चिंता करनी होगी। इसलिए, अनावश्यक फ़ील्ड जोड़े जाते हैं और संग्रह जोड़े जाते हैं। ओलेओर फ्रेमवर्क का मॉडल हर बार अपडेट किया जाता है, और सिस्टम अधिक से अधिक गंदा हो जाता है।

यह भी एक बड़ी समस्या है कि आप संबंध नहीं बना सकते। नहीं, ऐसे लोग हैं जो इसे पेस्ट कर सकते हैं। निश्चित रूप से एक DocReference प्रकार है। हालांकि, Django या Rails जैसे ढांचे का उपयोग किए बिना संबंधों को चिपकाने का कार्य बेहद खतरनाक है। यह एक आत्मघाती कृत्य है।

उदाहरण के लिए, आप कैसे पता लगाते हैं कि जब वस्तु का बिंदु मिट जाता है? बेशक मैं जवाब नहीं दे सकता। इसलिए, ओलेओर ढांचे को मिटाते समय व्यवहार और प्रबंधन फ़ंक्शन बनाना आवश्यक है। कौन? इसे कौन विकसित करेगा? यह आप है।

सबसे पहले, फायरस्टोर के लिए डीबी में डुबकी लगाना आदर्श है क्योंकि यह इसे सामान्य किए बिना है। यदि आप संबंधों को चिपकाने जैसे सामान्य करना चाहते हैं, तो आपको स्कीमालेस का उपयोग करने की आवश्यकता नहीं है, और आपको संबंधपरक डीबी पर विचार करना चाहिए। मैं दस्तावेज़-आधारित डेटाबेस में संबंधों को चिपकाने के बारे में नहीं सोचना चाहता हूं।

मैं आपको आश्वस्त कर सकता हूं, लेकिन एक दिन मुझे कई से कई टेबल की याद आती है और मैं मर रहा हूं। उस समय तक, आपको पछताना शुरू हो जाना चाहिए कि आपने फायरस्टोर को क्यों चुना।

Firestore के बारे में एक बुरी बात यह है कि इसका बैकअप लेना बहुत मुश्किल है। प्रोडक्शन से स्टेजिंग तक कॉपी करना आसान नहीं है, इसलिए बोलना है । यह विकास दक्षता को भी बहुत खराब बनाता है। कभी-कभी जब कोई सुविधा पूर्ण हो जाती है और आप एक परीक्षण चलाना चाहते हैं, तो आप उत्पादन से डेटा खींचना चाहते हैं (हालांकि यह वास्तव में अच्छा नहीं है) और इसे जांचें (दूसरी बार, लेकिन यह वास्तव में अच्छा नहीं है)। फायरबेस ऐसा नहीं कर सकता। क्योंकि उपयोगकर्ता डेटा माइग्रेट करना आसान नहीं है। जब ऐप का आकार उचित होता है, तो उपयोगकर्ता और फायरस्टोर कुछ (ज्यादातर यूआईडी) से जुड़े होते हैं, लेकिन चूंकि यह उपयोगकर्ता समूह को नहीं खींचता है, इसलिए उत्पादन वातावरण के डेटा का परीक्षण और पुष्टि करना बहुत मुश्किल है। यहां तक कि फायरस्टोर का माइग्रेशन भी मुश्किल है क्योंकि यह मैनेजमेंट स्क्रीन पर पॉप हो रहा है। आप सोच सकते हैं कि आपको फायरबेस लोकल एमुलेटर सूट का उपयोग करना चाहिए, लेकिन यह एक बहुत बड़ा अनुभव है, इसलिए इसे आजमाएं।

आखिरकार

फायरबेस ने इसे एक बार किया है, लेकिन यह आखिरी है । ऐसा इसलिए है क्योंकि प्रमाणीकरण भाग को दूसरे में स्थानांतरित करना आसान नहीं होगा क्योंकि यह उपयोगकर्ता द्वारा उपयोग किया जाता है।

इसलिए मैंने यह लेख यह सोचकर लिखा है कि जब स्टार्टअप पहली बार फायरस्टोर चुनते हैं तो उन्हें पारलौकिक पछतावे से मरना चाहिए ।

Firestore के साथ, मेरे पास इसके बारे में सोचने के लिए बहुत समय है। क्या करना है इसके बारे में बात करना पूरी तरह से बकवास है क्योंकि आप इसे नहीं कर सकते हैं, ट्विस्ट और टर्न का स्रोत कोड लिखें, अनावश्यक फ़ील्ड जोड़ें और परीक्षण करें, और विभिन्न चीजों की जांच करें। आपके पास कितना भी विकास समय क्यों न हो, यह पर्याप्त नहीं है।

फायरबेस निवेशकों के लिए सरल ऐप बनाने, प्रस्तुत करने, सेवाओं को आज़माने और अति-छोटी सेवाओं के लिए बहुत अच्छा है। यह उन इंजीनियरों के लिए भी उपयुक्त है जो रिलेशनल डेटाबेस से परिचित नहीं हैं।

कुछ मेरी कहानी के खिलाफ बहस करेंगे। यह एप्लिकेशन, विकास विधि और आकार पर निर्भर करता है, बैकअप विधि ऐसा नहीं है, इस विधि से संबंध हल किया जा सकता है, स्केलेबिलिटी उत्कृष्ट है, आदि।

मैं इसे सुनना नहीं चाहता, और मैं केवल उस फायरस्टोर का उपयोग करना चाहता हूं जो मुझे पसंद है।