टेक्नोब्लॉग: एवरनोट ने अपना एपीआई बनाने के लिए अपाचे थ्रिफ्ट को क्यों चुना

जब हमने योजना बनाना शुरू किया कि 2007 में एवरनोट सेवा को कैसे व्यवस्थित किया जाएगा, तो हम जानते थे कि पहले दिन हमें पतले (जैसे ब्राउज़र) और मोटे सिंक्रनाइज़ क्लाइंट दोनों के लिए समर्थन की आवश्यकता होगी। इसने वेब के लिए किसी भी GUI पर काम शुरू करने से पहले हमें दूरस्थ प्रोटोकॉल और क्लाइंट API के बारे में सोचने के लिए प्रेरित किया। अन्यथा, आपको मौजूदा वेब सेवा पर एपीआई खराब होने के लिए कई महीनों तक इंतजार करना होगा।

हमारे आवेदन एपीआई पर कुछ आवश्यकताओं को लगाते हैं, जैसे:

1. क्रॉस-प्लेटफॉर्म। जब हमने फरवरी 2008 में शुरू किया था, तो हमारे पास तैयार कोड था जो कि क्लाइंट साइड पर जावा और क्लाइंट साइड पर Win32 C ++ और कोको ऑब्जेक्टिव-सी का उपयोग करता था।
2. कॉम्पैक्ट डेटा ट्रांसफर। एवरनोट क्लाइंट एप्लिकेशन नोटों को सिंक्रनाइज़ करते हैं, जिसमें मेगाबाइट के दसियों की कुल मात्रा के साथ सैकड़ों एम्बेडेड चित्र हो सकते हैं। हम एक एपीआई रखना चाहते हैं जिसमें 15 मेगाबाइट नोट के हस्तांतरण का मतलब होगा कि इन 15 मेगाबाइटों का सटीक रूप से हस्तांतरण, और अधिक नहीं।
3. आगे / पीछे की संगतता। उपयोगकर्ता द्वारा एक बार हमारे क्लाइंट के संस्करण को उसके कंप्यूटर पर इंस्टॉल करने के बाद, हम उसे हर बार डेटा संरचना के हमारे मॉडल का विस्तार करने के लिए सॉफ़्टवेयर को अपडेट करने के लिए मजबूर नहीं करना चाहते हैं।
4. प्रोग्रामिंग भाषाओं के लिए बाइंडिंग (बाइंडिंग)। हम प्रत्येक ग्राहक के लिए डेटा संरचनाओं को पार्स करने और क्रमबद्ध करने के लिए बहुत सारे कोड नहीं लिखना चाहते थे। यह बहुत समय लेता है और त्रुटियों की ओर जाता है, और व्यवहार में तीसरे बिंदु को अव्यवहारिक बनाता है।
5. मानकों और / या खुले स्रोत के आधार पर। सभी चीजें समान हो रही हैं, हम स्पष्ट कारणों के लिए मालिकाना प्रौद्योगिकियों के साथ हमारी सेवा के एपीआई को जोड़ना नहीं चाहते थे।
6. सघनता। हम अपने प्रत्येक मोबाइल क्लाइंट के लिए एक मेगाबाइट कोड और 200 कक्षाएं जोड़ना पसंद नहीं करेंगे।

हमने कई महीनों तक विभिन्न विकल्पों पर शोध और परीक्षण किया। एक्सएमएल-आरपीसी या एसओएपी आवश्यकताओं में से एक (1, 5), जीरो से आईसीई - अन्य (2, 4) से मिला। कुछ बिंदु पर, हमने एक साइकिल का आविष्कार करने और अपने स्वयं के छोटे तदर्थ प्रोटोकॉल को रोल करने के बारे में भी सोचा।

हमारे एक मित्र ने हाल ही में खोले गए थ्रिफ्ट फ्रेमवर्क पर ध्यान देने की सिफारिश की, जिसका उपयोग फेसबुक पर किया गया था। फेसबुक ने अन्य आंतरिक सर्वरों के साथ संदेशों का आदान-प्रदान करने के लिए बैकएंड सर्वरों पर अपने आंतरिक काम में इसका उपयोग किया, जहां अक्सर विभिन्न भाषाओं में कोड युग्मन से निपटने के लिए आवश्यक था (उदाहरण के लिए, PHP और C ++)। और अन्य लोग, जहां तक ​​हम बता सकते हैं, एक समान कार्य के लिए थ्रिफ्ट का उपयोग किया गया: आंतरिक बैकएंड-सर्वर का संचार प्रदान करना।

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

1. क्रॉस प्लेटफॉर्म। हम थ्रिफ़्ट में इंटरफ़ेस परिभाषा भाषा (इंटरफ़ेस डेफिनिशन लैंग्वेज) का उपयोग करते हुए डेटा और सेवा संचालन के हमारे मॉडल को परिभाषित करते हैं, और संकलन के बाद हम आउटपुट पर एक दर्जन विभिन्न भाषाओं के लिए क्लाइंट-साइड और सर्वर-साइड कोड प्राप्त करते हैं।
2. कॉम्पैक्ट डेटा ट्रांसफर। यदि आप संरचना के विवरण में इंगित करते हैं कि एक बियानर क्षेत्र है और वहां 1 मेगाबाइट डेटा रखा गया है, तो परिणामस्वरूप यह 1 मेगाबाइट संचार चैनलों के माध्यम से प्रेषित किया जाएगा।
3. आगे / पीछे की संगतता। यह वह जगह है जहाँ थ्रिफ्ट वास्तव में अतुलनीय है। एक निश्चित सटीकता और समझ के साथ कि थ्रिफ्ट कैसे काम करता है (जो हमेशा तुरंत नहीं दिया जाता है, निश्चित रूप से), आप मौजूदा क्लाइंट्स का उल्लंघन किए बिना संरचनाओं, फ़ील्ड, उपयोगिता विधियों और फ़ंक्शन मापदंडों को जोड़ सकते हैं। विंडोज या मैक के लिए ग्राहक, जिसे हमने 3 साल पहले जारी किया था, और आज एवरनोट के साथ सिंक्रनाइज़ कर सकता है।
4. प्रोग्रामिंग भाषाओं के लिए बाइंडिंग (बाइंडिंग)। देखें बिंदु 1. बहुत शुरुआत में, थ्रिफ्ट में ऑब्जेक्टिव-सी कोको के लिए कोई समर्थन नहीं था, इसलिए एंड्रयू मैकगिची (मैक क्लाइंट को विकसित करने के लिए हमारी "मानव टीम") ने इस समर्थन को थ्रिफ्ट कंपाइलर में जोड़ा।
5. मानकों और / या खुले स्रोत के आधार पर। फेसबुक ने थ्रिफ्ट के विकास को अपाचे सॉफ्टवेयर फाउंडेशन में स्थानांतरित कर दिया, जो उनमें से बहुत उदार है।
6. सघनता। थ्रिफ्ट एक्जीक्यूटेबल लाइब्रेरिज और जेनरेट किए गए कोड बहुत छोटे और समझ में आने वाले थे। वे आसानी से पढ़ और समझ सकते हैं कि वे क्या कर रहे हैं (तब से, हालांकि, यह कुछ अतिरिक्त कोड के साथ अतिवृद्धि हो गया है, लेकिन आज भी, हमारी राय में, यह अभी भी विकल्पों की तुलना में सबसे कॉम्पैक्ट विकल्प है)।

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

आपके बारे में क्या?

आप अपनी वेब सेवा के लिए एपीआई लागू करने वाले हैं। क्या आपको थ्रिफ्ट का उपयोग करना चाहिए?

यदि आपके आवेदन में एवरनोट के समान आवश्यकताएं हैं, तो थ्रिफ्ट एक अच्छा विकल्प हो सकता है। यदि आप बड़े बाइनरी संरचनाओं (धारा 2) के साथ एक जटिल डेटा मॉडल में नहीं आते हैं, तो उत्तर इतना स्पष्ट नहीं है।

सरल डेटा मॉडल के साथ वेब सेवाएँ आमतौर पर XML या JSON के माध्यम से डेटा क्रमांकन के साथ कम परिष्कृत REST प्रोटोकॉल का उपयोग करती हैं। यह दृष्टिकोण सरल संचालन को वास्तव में परीक्षण और निष्पादित करने में आसान बना देगा। अगर मुझे ट्विटर एपीआई का उपयोग करके कुछ चीजें करने की आवश्यकता है , तो मैं उन्हें मैन्युअल रूप से कमांड लाइन से कर्ल / विग के साथ परीक्षण कर सकता हूं और प्रिंटफ / प्रिंटल / रीजेक्स, आदि के माध्यम से कोड को अपने आवेदन में पेंच कर सकता हूं। इसका मतलब है कि स्वतंत्र डेवलपर्स के लिए एक शुरुआती बाधा है जो इस प्रकार के एपीआई के साथ काम करना शुरू करें, बहुत कम।

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

दूसरी ओर, डेटा के सरलीकृत अप्रकाशित क्रमांकन के साथ इन प्रकार के एपीआई के लिए कम बाधा, एक नियम के रूप में, बाद की संगतता समस्याओं (धारा 3) में परिणाम है। हमारा Twitter गेटवे REST- आधारित Twitter API के साथ सहभागिता करने के लिए स्वतंत्र Twitter4J लाइब्रेरी का उपयोग करता है। पिछले साल, ट्विटर के सर्वर साइड में बदलाव और बाद में ट्विटर 4 जे पर एक्सएमएल डेटा संरचनाओं की गलत व्याख्या के कारण हमारा प्रवेश द्वार कम से कम टूट गया (उदाहरण के लिए, ट्वीट पहचानकर्ता की लंबाई)।

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