360 पिवट या हमने कौन से समाधान का उपयोग किया। भाग 1

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

पिछले साल दिसंबर में, हमने iknow.travel परियोजना के साथ इस बाजार में प्रवेश किया, एयरलाइन टिकट और एक सामग्री संसाधन की बिक्री के संयोजन पर दांव लगाया, लेकिन 3 महीने (फरवरी में) के बाद हमने स्क्रैच से परियोजना को फिर से लिखने का फैसला किया, और हमने टिकट भाग को वापस नहीं लिया। उस समय परीक्षण करें।

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

क्या था?

क्या बन गया है?

क्या किया

प्रारंभ में, हम एक लक्ष्य निर्धारित करते हैं: साइट को पूरी तरह से खोज इंजन के लिए खुला छोड़ने के लिए, जबकि इसे एकल-पृष्ठ एप्लिकेशन की शैली में बनाते हैं। एक-पृष्ठ साइटों को एसईओ में कठिनाई होती है। ऐसे मामलों में Google तथाकथित हैश फ़्रैगमेंट की सिफारिश करता है। लब्बोलुआब यह है: सभी लिंक "#!" से शुरू होते हैं, और रोबोट केवल "#!" बदलता है। "? _escaped_fragment =", एक अनुरोध करता है और स्थिर HTML की प्रतिक्रिया में प्रतीक्षा करता है। और यह काम करता है। हमने अच्छी पुरानी पद्धति को प्राथमिकता दी। अधिकांश साइट HTML में उपलब्ध है, जो खोज इंजनों को नियमित स्थिर साइट पर पृष्ठों को देखने की अनुमति देती है (हालांकि कोई समझौता नहीं था)। सच है, ऐसी अफवाहें हैं कि Googlebot पहले से ही AJAX को समझता है , लेकिन किसी तरह हम उन पर भरोसा करने के लिए इच्छुक नहीं हैं। और एक नियमित ब्राउज़र के साथ हम HTML5 PushState पर काम करते हैं (जो IE 9 को छोड़कर सभी आधुनिक ब्राउज़रों में समर्थित है), यदि HTML5 PushState उपलब्ध नहीं है, तो हैश URL पर एक स्वचालित संक्रमण के साथ। और आप कैसे करेंगे?

अगला, स्टैक चयन

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

रीढ़

हमारा ग्राहक Backbone पर आधारित है। बैकबोन - इंटरैक्टिव अनुप्रयोगों के लिए जेएस फ्रेमवर्क। सब कुछ 4 अवधारणाओं के आधार पर बनाया गया है:

• आदर्श
• राय
• संग्रह
• रूटर

बैकबोन में उनकी व्याख्या आम तौर पर स्वीकृत से भिन्न होती है। सबसे पहले, मॉडल को आधार से अलग किया जाता है। शामिल REST CRUD API के लिए एक बाइंडिंग है, लेकिन HTML5 LocalStorage , WebSockets के लिए एडेप्टर हैं। दूसरे, देखें आमतौर पर एक दृश्य भी नहीं है, लेकिन सामान्य अर्थों में एक नियंत्रक। मैं एक आरक्षण दूंगा कि शब्दावली विशुद्ध रूप से व्यक्तिपरक मामला है, और बैकबोन लेखक सीधे कहते हैं: उनकी तैयारी किसी भी दृष्टिकोण के लिए खुली है । एक दृष्टिकोण को चुनना और उसका पालन करना बहुत महत्वपूर्ण है। आप क्या कहते हैं?
वैसे, बैकबोन के साथ शुरू करने के लिए, हम अनुशंसा करते हैं कि आप इसे देखें (हम हैबर के लिए अनुवाद करने में प्रसन्न होंगे - यदि आवश्यक हो तो लिखें)।

MongoDB

उस तकनीक के विकल्प के साथ समानांतर में जिस पर ग्राहक बनाया जाएगा, हमें डेटा स्टोरेज के लिए DBMS चुनने के सवाल का सामना करना पड़ा।

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

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

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

परिणाम

यदि आप यह देखने के लिए इच्छुक हैं कि अंत में क्या हुआ और यह कैसे काम करता है, तो परीक्षण के लिए हमने यहां अद्यतन परियोजना पोस्ट की।
पुरानी साइट पर हवाई टिकट (यदि कोई वहां पहुंचना चाहता है) तक पहुंचने के लिए, कोड का उपयोग करें: i3n7wt0a8el

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