मुझे लगता है कि इस प्रश्न के बारे में मुझे क्या गुस्सा आता है कि आपने इसे रद्द कर दिया है और इसे एक निश्चित संख्या में इकट्ठा करने के प्रयास में "तथ्यों" के साथ लोड किया है।
सच्चाई यह है कि आप एक ऐप इंजन ऐप विकसित कर सकते हैं जो फेसबुक, ट्विटर या टंबलर की विशेषताओं की नकल करता है। और यह मानते हुए कि ऐप को अच्छी तरह से लिखा गया था, यह सैकड़ों लाखों उपयोगकर्ताओं का समर्थन करने के लिए तैयार होगा। मुख्य कारण जिसे आप नहीं चाहते हैं (जो आपके लिए एक विचार नहीं है) ऐप इंजन पर आकार देने वाली सेवा को चलाने की लागत है।
इसके अलावा, मैं यह देखने में विफल रहता हूं कि आपके द्वारा सूचीबद्ध किसी भी प्रतिबंध से आप इस तरह के ऐप को विकसित करने से कैसे रोक पाएंगे।
HTTP रिक्वेस्ट / रिस्पांस
- अधिकतम अनुरोध का आकार: 10 एमबी - गलत, 32 एमबी तक बढ़ा दिया गया।
- अधिकतम प्रतिक्रिया आकार: 10 एमबी - गलत, 32 एमबी तक बढ़ा दिया गया।
- यदि आप एक सामाजिक ऐप विकसित कर रहे हैं, जिसे अक्सर 10MB से बड़े पृष्ठों को वितरित करने की आवश्यकता होती है, तो आप शायद इसे गलत कर रहे हैं। इसके अलावा, यदि आपको 32MB से अधिक की सामग्री वितरित करने की आवश्यकता है, तो आप 2GB तक की फ़ाइलों के लिए ब्लॉस्टस्टोर का उपयोग कर सकते हैं।
- आप फ़ाइल सिस्टम तक नहीं पहुँच सकते। (फाइलसिस्टम पर अपलोड को सहेजने के बारे में भूल जाएं) - गलत। आप स्थानीय फ़ाइल सिस्टम से पढ़ सकते हैं और ब्लॉबस्टोर पर फ़ाइल को अपलोड और पढ़ / लिख सकते हैं।
- ऐसा कोई तरीका नहीं है कि फेसबुक, ट्विटर या टम्बलर केवल उपयोगकर्ता अपलोड ले रहे हैं और उन्हें एक फ़ोल्डर में कॉपी कर रहे हैं। कोई समस्या नहीं।
- सभी अनुरोधों को 10 मिनट के भीतर जवाब देना होगा अन्यथा जीएई डेडलाइन को बढ़ा देगा। अपवाद - गलत। यह वास्तव में 30 सेकंड है।
- यदि आपको उपयोगकर्ता के अनुरोध पर परिणाम देने के लिए 30 सेकंड से अधिक समय की आवश्यकता है, तो आप शायद गलत कर रहे हैं।
- प्रत्येक क्रोन नौकरी को 30 सेकंड के भीतर निष्पादित किया जाना चाहिए - गलत, यह 10 मिनट है।
- यदि आप 10 मिनट के समय में एक लंबा काम नहीं कर सकते हैं, तो ए: आप शायद इसे गलत कर रहे हैं और बी: आप अब उस कार्य को बैकएंड उदाहरण में स्थानांतरित कर सकते हैं, जिसमें अनुरोधों पर समय सीमा नहीं है।
क्रॉन जॉब्स मैप कम करने का उपयोग नहीं कर सकते हैं - कभी भी मैप कम नहीं किया जाता है, लेकिन मुझे लगता है कि इसके लिए प्रशस्ति पत्र की आवश्यकता है।
प्रत्येक GET या POST किसी अन्य साइट पर 5 सेकंड के बाद छोड़ दिया जाता है। आप इसे अधिकतम 10 सेकंड तक प्रतीक्षा करने के लिए कॉन्फ़िगर कर सकते हैं। (मध्यवर्ती सर्वर कई बार ट्विटर और फेसबुक के साथ काम करना आवश्यक होगा) - ट्रू।
- अगर किसी बाहरी एपीआई के लिए उपयोगकर्ता का सामना करने का अनुरोध 10 सेकंड से अधिक समय ले रहा है, तो उपयोगकर्ता को किसी भी तरह से फिर से बताने के लिए यह एक अच्छा विचार है। यदि यह उपयोगकर्ता-सामना का अनुरोध नहीं है, तो आप स्वचालित रूप से कार्य का पुनः प्रयास कर सकते हैं जब तक कि एपीआई जवाब नहीं देता।
- एफ़टीपी (केवल एचटीटीपी और एचटीटीपीएस) के माध्यम से ग्राहक जीएई से कनेक्ट नहीं हो सकता है। - सच
-- यह एक मुद्दा क्यों है? क्या आपको लगता है कि कोई भी बड़े पैमाने पर कंपनी एफ़टीपी के माध्यम से परिवर्तन दर्शाती है?
- कस्टम डोमेन के लिए कोई https नहीं। केवल अपने-app-id.appspot.com डोमेन के लिए। - सच।
- यह हालांकि रोडमैप पर है।
- यदि आपको उपयोगकर्ताओं की आमद मिलती है, तो आपको "ओवर कोटा" त्रुटि मिलती है - आधा सच।
- यदि आप अपने ऐप को ठीक से बजट करते हैं तो आपको कभी ओवर कोटे की त्रुटि नहीं दिखाई देगी। रॉयल वेडिंग साइट को ऐप इंजन पर होस्ट किया गया और प्रति सेकंड 32,000 अनुरोध प्राप्त हुए। कोटा त्रुटियों पर नहीं। इसके अलावा, कभी भी ट्विटर पर फेल व्हेल या टंबलर की ओवर क्षमता त्रुटि देखी गई? यह अनिवार्य रूप से उनकी ओवर कोटा त्रुटि है।
डेटाबेस
- वास्तविक सर्वर की तुलना में स्थानीय विकास में डेटाबेस व्यवहार समान नहीं है। - असत्य
- अगर आपका मतलब है कि आपके लैपटॉप पर डेटास्टोर चलाना ऐप इंजन के क्लस्टर पर चलने की तुलना में धीमा है, तो सच है, अन्यथा बिल्कुल भी सच नहीं है।
- GQL। और कुछ नहीं। - असत्य
- अधिकांश डेवलपर्स डेटास्टोर को क्वेरी करने के लिए db फ़िल्टर का उपयोग करते हैं। इसके अलावा, आप समान रूप से कह सकते हैं कि MySQL "SQL। कुछ और नहीं" की अनुमति देता है।
- कोई भी क्वेरी 1000 से अधिक रिकॉर्ड प्राप्त नहीं कर सकती है (यदि आप अपने क्लाइंट को एक क्लिक-गो-ऑफ़लाइन-अब बटन करना चाहते हैं तो गंभीरता से बेकार है) - गलत।
- 1000 रिकॉर्ड की सीमा को बहुत पहले उठा लिया गया था। इसके अलावा, मुझे फ़ेसबुक, ट्विटर या टम्बलर पर कोई भी उपयोगकर्ता-संबंधी पृष्ठ दिखाएं, जिसे रेंडर करने के लिए 1000 से अधिक रिकॉर्ड की आवश्यकता हो।
- यदि आपको ऑपरेशन करने के लिए रिकॉर्ड की एक बड़ी मात्रा में रैखिक पहुंच की आवश्यकता है, तो आप भाग्य से बाहर हैं (Google के सिस्टम बड़े पैमाने पर क्लस्टर हैं)
- मुझे भी यकीन नहीं है कि आप यहाँ क्या कर रहे हैं। अधिकांश लोग Google के विशाल क्लस्टर की गति को सिस्टम का एक बड़ा लाभ मानते हैं।
Memcache मान अधिकतम आकार 10 MB है। - वास्तव में यह 1 एमबी प्रति मेमेक प्रविष्टि है, जो हर दूसरे मेकचे के कार्यान्वयन के समान है।
सरल पाठ खोज नहीं कर सकते - सच है।
- यह एक विशेषता है जो डेक पर है। अधिकांश बड़ी साइटें अपने स्वयं के पाठ खोज अनुक्रमण नहीं करती हैं।
- आप 2 तालिकाओं में शामिल नहीं हो सकते। - सच।
- ऐप इंजन डेवलपर्स को अपनी सोच को एक बड़े पैमाने पर मल्टी-जॉइन एसक्यूएल क्वेरी से कई छोटे-छोटे व्यक्तिगत प्रश्नों को समायोजित करने की आवश्यकता होती है, या डेटा को असामान्य कर देते हैं ताकि जॉइन की आवश्यकता न हो।
- धीमा (आपको विरासत के उपयोग से तालिकाओं को अलग करने के तरीके के बारे में पढ़ना होगा ताकि आप तालिका में खोज कर सकें, कुंजी प्राप्त कर सकें और फिर अपने माता-पिता को डिसेरिएलाइजेशन प्रदर्शन से बचने के लिए प्राप्त कर सकें) - ???
- अनुवाद / उद्धरण की आवश्यकता।
- "बहुत अधिक सूचकांक" रनटाइम अपवाद - सही
- किसी एक ऐप में इंडेक्स की संख्या की सीमा होती है। मैंने केवल अकादमिक अनुसंधान अनुप्रयोगों को देखा है, हालांकि इसे मारा।
- एक इंडेक्स में इंडेक्स में 5000 से अधिक संपत्ति मान हो सकते हैं - ट्रू
- इसलिए अगर किसी के पास 5000 से अधिक दोस्त हैं तो उन्हें मित्र समूह में दो संस्थाओं की आवश्यकता होगी।
- प्रपत्र के मुख्य नाम
__*__(दो अंडरस्कोर के साथ शुरू और अंत) आरक्षित हैं, और आवेदन द्वारा उपयोग नहीं किया जाना चाहिए। - सच
-- लेकिन तो क्या?
- मुख्य नाम 500 बाइट्स तक सीमित हैं (UTF-8 एनकोडेड, मुझे लगता है) - ट्रू
- फिर, तो क्या? उपन्यासों के भंडारण के लिए मुख्य नाम नहीं हैं, वे विशिष्ट रूप से एक इकाई की पहचान करने के लिए हैं।
भाषा: हिन्दी
- अजगर या जावा या गो (कुछ और भी इन भाषाओं में अनुवादित करना होगा) - आधा सच
- दरअसल आप JVM पर चलने वाली किसी भी भाषा को भी चला सकते हैं, जिसमें PHP और JRuby शामिल हैं। सुनिश्चित नहीं है कि यह एक मुद्दा क्यों है, पाइथन और जावा दो शक्तिशाली भाषाएं हैं जिनमें बहुत सारे उपलब्ध टूल, ट्यूटोरियल और अनुभवी प्रोग्रामर हैं।
सेवा के मामले
- कोई स्थिर आईपी (थ्रॉटलिंग और कोटा समस्याओं को तीसरे पक्ष के एपीआई कॉल करना) - आधा सच
- अधिकांश थर्ड पार्टी एपीआई ऐप इंजन के बारे में जानते हैं और / या Google के साथ संबंध रखते हैं। कुछ बार ट्विटर ने गलती से ऐप इंजन को अवरुद्ध कर दिया है और यह कुछ घंटों में ठीक हो जाता है।
- प्रत्येक एप्लिकेशन 3000 फ़ाइलों तक सीमित है - आधा सच
- यदि आपको वास्तव में अपने वेब एप्लिकेशन के लिए 3000 से अधिक कोड फ़ाइलों की आवश्यकता है तो आप ज़िप आयात का उपयोग कर सकते हैं (इसके अलावा, आप इसे गलत कर रहे हैं)।
- वेब ऐप चलाने वाले OS या हार्डवेयर का कोई नियंत्रण नहीं - सच
- ऐप इंजन सेवा के रूप में एक प्लेटफ़ॉर्म है । ओएस या हार्डवेयर की सेवा के बारे में चिंता करने की ज़रूरत नहीं है कि लोग क्या कर रहे हैं। यह ऐप इंजन का मुख्य लाभ है, न कि सीमा।