REST API के रूप में थ्रिफ्ट

क्लाइंट और सर्वर विकास टीमों के बीच काम को सिंक्रनाइज़ करने की समस्याओं में हम कैसे भागे, इसके बारे में एक संक्षिप्त लेख। हमारी टीमों के बीच बातचीत को सरल बनाने के लिए हमने थ्रिफ़्ट को कैसे जोड़ा।

कौन परवाह करता है कि हमने यह कैसे किया, और हमने जो "साइड" इफेक्ट पकड़े, कृपया बिल्ली के नीचे देखें।

प्रागितिहास

2017 की शुरुआत में, जब हमने एक नई परियोजना शुरू की, तो हमने EmberJS को दृश्यपटल के रूप में चुना। जो, लगभग स्वतः ही हमें REST योजना पर काम करने के लिए प्रेरित करता है जब अनुप्रयोग के क्लाइंट और सर्वर भागों की सहभागिता को व्यवस्थित करता है। क्योंकि EmberData बैकएंड और फ्रंटएंड कमांड के काम को अलग करने के लिए एक सुविधाजनक उपकरण प्रदान करता है, और एडेप्टर का उपयोग करने से आपको इंटरैक्शन के "प्रोटोकॉल" का चयन करने की अनुमति मिलती है।

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

परियोजना का विकास

अब हम EmberJS को VueJS के पक्ष में छोड़ रहे हैं। और प्रवास के निर्णय के हिस्से के रूप में, हमने इस समस्या के समाधान की तलाश शुरू की। निम्नलिखित मानदंड विकसित किए गए थे:

• प्रोटोकॉल के पुराने और नए संस्करणों के साथ संगतता
• "सर्वर के बिना" काम करते समय फ्रंटएंड डेवलपर्स के लिए अधिकतम सुविधा
• परीक्षण डेटा से एपीआई विवरण को अलग करना
• आसान कॉल हस्ताक्षर सिंक्रनाइज़ेशन
  • स्पष्ट हस्ताक्षर विवरण
  • फ्रंटएंड और बैकएंड डेवलपर्स दोनों द्वारा संशोधन में आसानी
  • अधिकतम स्वायत्तता
• मजबूत टाइप किए गए एपीआई वांछनीय हैं। यानी एक प्रोटोकॉल परिवर्तन के तथ्य का सबसे तेज़ पता लगाना
• सर्वर लॉजिक का परीक्षण करने में आसानी
• तम्बूरे के साथ नृत्य के बिना सर्वर की ओर से वसंत के साथ एकीकरण।

कार्यान्वयन

सोचने के बाद थ्रिफ्ट पर रुकने का फैसला किया गया। इससे हमें एक सरल और स्पष्ट एपीआई विवरण भाषा मिली।

namespace java ru.company.api namespace php ru.company.api namespace javascrip ru.company.api const string DIRECTORY_SERVICE= "directoryService" exception ObjectNotFoundException{ } struct AdvBreed { 1: string id, 2: string name, 3: optional string title } service DirectoryService { list<AdvBreed> loadBreeds() AdsBreed getAdvBreedById(1: string id) } 

बातचीत के लिए, हम TMultiplexedProcessor का उपयोग करते हैं, TServlet के माध्यम से सुलभ, TJSONProtocol का उपयोग करते हुए। इस थ्रिफ्ट को मूल रूप से स्प्रिंग के साथ एकीकृत करने के लिए मुझे थोड़ा नृत्य करना पड़ा। ऐसा करने के लिए, मुझे सर्वलेट में एक सर्वलेट को प्रोग्रामेटिक रूप से बनाना और पंजीकृत करना था।

 @Component class ThriftRegister : ApplicationListener<ContextRefreshedEvent>, ApplicationContextAware, ServletContextAware { companion object { private const val unsecureAreaUrlPattern = "/api/v2/thrift-ns" private const val secureAreaUrlPattern = "/api/v2/thrift" } private var inited = false private lateinit var appContext:ApplicationContext private lateinit var servletContext:ServletContext override fun onApplicationEvent(event: ContextRefreshedEvent) { if (!inited) { initServletsAndFilters() inited = true } } private fun initServletsAndFilters() { registerOpenAreaServletAndFilter() registerSecureAreaServletAndFilter() } private fun registerSecureAreaServletAndFilter() { registerServletAndFilter(SecureAreaServlet::class.java, SecureAreaThriftFilter::class.java, secureAreaUrlPattern) } private fun registerOpenAreaServletAndFilter() { registerServletAndFilter(UnsecureAreaServlet::class.java, UnsecureAreaThriftFilter::class.java, unsecureAreaUrlPattern) } private fun registerServletAndFilter(servletClass:Class<out Servlet>, filterClass:Class<out Filter>, pattern:String) { val servletBean = appContext.getBean(servletClass) val addServlet = servletContext.addServlet(servletClass.simpleName, servletBean) addServlet.setLoadOnStartup(1) addServlet.addMapping(pattern) val filterBean = appContext.getBean(filterClass) val addFilter = servletContext.addFilter(filterClass.simpleName, filterBean) addFilter.addMappingForUrlPatterns(null, true, pattern) } override fun setApplicationContext(applicationContext: ApplicationContext) { appContext = applicationContext } override fun setServletContext(context: ServletContext) { this.servletContext = context } } 

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

एक नई सेवा को जोड़ने के लिए, आपको थोड़ा अतिरिक्त कोड लिखना होगा।

 @Component class DirectoryServiceProcessor @Autowired constructor(handler: DirectoryService.Iface): DirectoryService.Processor<DirectoryService.Iface>(handler) 

और प्रोसेसर को पंजीकृत करें

 @Component class SecureMultiplexingProcessor @Autowired constructor(dsProcessor: DirectoryServiceProcessor) : TMultiplexedProcessor() { init { this.registerProcessor(DIRECTORY_SERVICE, dsProcessor) ... } } 

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

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

क्लाइंट साइड पर मुख्य प्रोसेसिंग पॉइंट हमारे द्वारा लिखा गया थ्रिफ्ट-प्लगइन है।

 import store from '../../store' import { UNAUTHORIZED } from '../../store/actions/auth' const thrift = require('thrift') export default { install (Vue, options) { const DirectoryService = require('./gen-nodejs/DirectoryService') let _options = { transport: thrift.TBufferedTransport, protocol: thrift.TJSONProtocol, path: '/api/v2/thrift', https: location.protocol === 'https:' } let _optionsOpen = { ... } const XHRConnectionError = (_status) => { if (_status === 0) { .... } else if (_status >= 400) { if (_status === 401) { store.dispatch(UNAUTHORIZED) } ... } } let bufers = {} thrift.XHRConnection.prototype.flush = function () { var self = this if (this.url === undefined || this.url === '') { return this.send_buf } var xreq = this.getXmlHttpRequestObject() if (xreq.overrideMimeType) { xreq.overrideMimeType('application/json') } xreq.onreadystatechange = function () { if (this.readyState === 4) { if (this.status === 200) { self.setRecvBuffer(this.responseText) } else { if (this.status === 404 || this.status >= 500) {... } else {... } } } } xreq.open('POST', this.url, true) Object.keys(this.headers).forEach(function (headerKey) { xreq.setRequestHeader(headerKey, self.headers[headerKey]) }) if (process.env.NODE_ENV === 'development') { let sendBuf = JSON.parse(this.send_buf) bufers[sendBuf[3]] = this.send_buf xreq.seqid = sendBuf[3] } xreq.send(this.send_buf) } const mp = new thrift.Multiplexer() const connectionHostName = process.env.THRIFT_HOST ? process.env.THRIFT_HOST : location.hostname const connectionPort = process.env.THRIFT_PORT ? process.env.THRIFT_PORT : location.port const connection = thrift.createXHRConnection(connectionHostName, connectionPort, _options) const connectionOpen = thrift.createXHRConnection(connectionHostName, connectionPort, _optionsOpen) Vue.prototype.$ThriftPlugin = { DirectoryService: mp.createClient('directoryService', DirectoryService, connectionOpen), } } } 

इस प्लगइन को सही ढंग से काम करने के लिए, आपको उत्पन्न कक्षाओं को कनेक्ट करना होगा।

क्लाइंट पर सर्वर विधियों को कॉल करना इस प्रकार है:

 thriftPlugin.DirectoryService.loadBreeds() .then(_response => { ... }) .catch(error => { ... }) }) 

यहाँ मैं खुद VueJS की सुविधाओं में नहीं आया, जहां सर्वर को कॉल करने वाले कोड को रखना सही है। इस कोड का इस्तेमाल कंपोनेंट के अंदर और रूट दोनों के अंदर और Vuex-action के अंदर किया जा सकता है।
क्लाइंट पक्ष के साथ काम करते समय, कुछ सीमाएँ होती हैं जिन्हें आंतरिक थ्रिफ़ एकीकरण से मानसिक प्रवास के बाद ध्यान में रखा जाना चाहिए।

• जावास्क्रिप्ट क्लाइंट शून्य मानों को नहीं पहचानता है। इसलिए, उन क्षेत्रों के लिए जो शून्य हो सकते हैं, आपको वैकल्पिक ध्वज को निर्दिष्ट करना होगा। इस स्थिति में, क्लाइंट इस मान को सही ढंग से स्वीकार करेगा।
• जावास्क्रिप्ट को पता नहीं है कि लंबे मानों के साथ कैसे काम करना है, इसलिए सभी पूर्णांक पहचानकर्ताओं को सर्वर साइड पर स्ट्रिंग करना होगा

निष्कर्ष

थ्रिफ्ट के संक्रमण ने हमें उन समस्याओं को हल करने की अनुमति दी जो इंटरफ़ेस के पुराने संस्करण पर काम करते समय सर्वर और क्लाइंट विकास के बीच बातचीत में मौजूद हैं। एक स्थान पर वैश्विक त्रुटियों के प्रसंस्करण को संभव बनाने की अनुमति दी।

उसी समय, अतिरिक्त बोनस के साथ, एपीआई के सख्त टाइपिंग के कारण, और इसलिए सख्त डेटा सीरियललाइज़ेशन / डीसर्लाइज़ेशन नियमों के कारण, हमने अधिकांश अनुरोधों के लिए क्लाइंट और सर्वर पर बातचीत के समय में ~ 30% की वृद्धि प्राप्त की (जब REST और THRIFT इंटरैक्शन के माध्यम से समान अनुरोधों की तुलना की गई) प्रतिक्रिया प्राप्त होने तक सर्वर से अनुरोध भेजा गया था)