क्या गलत है रेखांकन के साथ

हाल ही में, GraphQL अधिक से अधिक लोकप्रियता प्राप्त कर रहा है। अनुरोध, टंकण और सदस्यता के सुंदर वाक्यविन्यास।

ऐसा लगता है: "यहां यह है - हमने डेटा विनिमय के लिए आदर्श भाषा ढूंढ ली है!" ...

मैं एक साल से अधिक समय से इस भाषा का उपयोग कर रहा हूं, और मैं आपको बताऊंगा: सब कुछ इतना सुचारू है। रेखांकन में असुविधाजनक क्षण और भाषा डिजाइन में वास्तव में मौलिक समस्याएं हैं।

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

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

1. NON_NULL

यह कोई गंभीर समस्या नहीं है। बल्कि, यह इस बात से संबंधित असुविधाओं की एक पूरी श्रृंखला है कि ग्राफक्यूएल में अशक्त के साथ काम कैसे आयोजित किया जाता है।

प्रोग्रामिंग भाषाएं कार्यात्मक (और न केवल) हैं, इस तरह के एक प्रतिमान मठ है। तो, Maybe (हास्केल) या Option (स्काला) मोनड के रूप में ऐसी चीज है। निचला रेखा यह है कि इस तरह के एक मोनड के भीतर निहित मूल्य मौजूद हो सकता है या नहीं (जो कि अशक्त हो सकता है)। ठीक है, या इसे एनम के माध्यम से लागू किया जा सकता है, जैसे कि जंग में।

एक तरह से या किसी अन्य, और अधिकांश भाषाओं में, यह मान, जो मूल को "लपेटता" है, मुख्य को एक अतिरिक्त विकल्प देता है। और वाक्यात्मक रूप से - यह हमेशा मुख्य प्रकार के लिए एक अतिरिक्त है। यह हमेशा केवल एक अलग प्रकार का वर्ग नहीं है - कुछ भाषाओं में, क्या यह प्रत्यय या उपसर्ग के रूप में सिर्फ एक जोड़ है ? ।

GraqhQL में, विपरीत सच है। सभी प्रकार डिफ़ॉल्ट रूप से अशक्त हैं - और यह केवल अशक्त के रूप में प्रकार को चिह्नित नहीं कर रहा है, यह इसके विपरीत, Maybe मोनाड है।

और अगर हम ऐसी योजना के लिए name क्षेत्र के आत्मनिरीक्षण खंड पर विचार करते हैं:

 #       schema -  ,    schema { query: Query } type Query { #       NonNull name: String! } 

हम पाते हैं:

String प्रकार NON_NULL में लिपटे

1.1। आउटपुट

ऐसा क्यों? संक्षेप में, यह डिफ़ॉल्ट "सहिष्णु" भाषा के डिजाइन (अन्य बातों के अलावा, यह माइक्रोसैस आर्किटेक्चर के अनुकूल है) से जुड़ा हुआ है।

इस "सहिष्णुता" के सार को समझने के लिए, थोड़ा और जटिल उदाहरण पर विचार करें, जिसमें सभी लौटे मानों को कड़ाई से NON_NULL में लपेटा गया है:

 type User { name: String! #  :       . friends: [User!]! } type Query { #  :       . users(ids: [ID!]!): [User!]! } 

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

 type User { name: String! #    -  null   . #    ""  -      ,    . friends: [User!] } 

यह आंतरिक त्रुटियों के प्रति सहनशीलता है। एक उदाहरण, निश्चित रूप से, दूर की कौड़ी है। लेकिन मुझे आशा है कि आपने सार को समझ लिया है।

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

 type Query { #  null   . #                . users(ids: [ID!]!): [User]! } 

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

मैं इस व्यवहार को "उल्टा" करने में सक्षम होना चाहता हूं, और विस्मयादिबोधक बिंदुओं के बजाय प्रश्न चिह्न लगाता हूं) यह किसी भी तरह अधिक परिचित होगा।

1.2। इनपुट

लेकिन प्रवेश करते समय, अशक्त एक पूरी तरह से अलग कहानी है। यह HTML में चेकबॉक्स स्तर का एक जंब है (मुझे लगता है कि हर कोई इस गैर-स्पष्टता को याद करता है जब एक अनियंत्रित चेकबॉक्स का क्षेत्र बस वापस नहीं भेजा जाता है)।

एक उदाहरण पर विचार करें:

 type Post { id: ID! title: String! #  :     null description: String content: String! } input PostInput { title: String! #  :     ,   description: String content: String! } type Mutation { createPost(post: PostInput!): Post! } 

अब तक, इतना अच्छा। अपडेट जोड़ें:

 type Mutation { createPost(post: PostInput!): Post! updatePost(id: ID!, post: PostInput!): Post! } 

और अब सवाल यह है कि पोस्ट को अपडेट करते समय हम विवरण क्षेत्र से क्या उम्मीद कर सकते हैं? क्षेत्र अशक्त हो सकता है, या अनुपस्थित हो सकता है।

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

2. इनपुट और आउटपुट का पृथक्करण

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

 type Post { input output text: String! output updatedAt(format: DateFormat = W3C): Date! } 

या निर्देशों का उपयोग:

 type Post { text: String! @input @output updatedAt(format: DateFormat = W3C): Date! @output } 

3. बहुरूपता

इनपुट और आउटपुट में प्रकारों को अलग करने की समस्याएं एक दोहरे विवरण तक सीमित नहीं हैं। एक ही समय में, सामान्य प्रकारों के लिए आप सामान्यीकृत इंटरफेस को परिभाषित कर सकते हैं:

 interface Commentable { comments: [Comment!]! } type Post implements Commentable { text: String! comments: [Comment!]! } type Photo implements Commentable { src: URL! comments: [Comment!]! } 

या यूनियनों

 type Person { firstName: String, lastName: String, } type Organiation { title: String } union Subject = Organiation | Person type Account { login: String subject: Subject } 

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

 union Subject = OrganiationInput | PersonInput input AccountInput { login: String! password: String! subject: Subject! } 

 #     { account: AccountInput { login: "Acme", password: "***", subject: OrganiationInput { title: "Acme Inc" } } } 

 #      { account: AccountInput { login: "Acme", password: "***", subject: PersonInput { firstName: "Vasya", lastName: "Pupkin", } } } 

लेकिन इससे इस व्यवसाय के लिए अतिरिक्त पार्सर लिखना आवश्यक हो जाएगा।

4. पीढ़ी

जेनेरिक के साथ GraphQL के साथ गलत क्या है? और सब कुछ सरल है - वे नहीं हैं। आइए एक पृष्ठांकन या कर्सर के साथ एक विशिष्ट CRUD इंडेक्स क्वेरी लें - यह महत्वपूर्ण नहीं है। मैं पेजेशन के साथ एक उदाहरण दूंगा।

 input Pagination { page: UInt, perPage: UInt, } type Query { users(pagination: Pagination): PageOfUsers! } type PageOfUsers { total: UInt items: [User!]! } 

और अब संगठनों के लिए

 type Query { organizations(pagination: Pagination): PageOfOrganizations! } type PageOfOrganizations { total: UInt items: [Organization!]! } 

और इसी तरह ... मैं कैसे इसके लिए जेनरिक रखना चाहूंगा

 type PageOf<T> { total: UInt items: [T!]! } 

तब मैं सिर्फ लिखूंगा

 type Query { users(page: UInt, perPage: UInt): PageOf<User>! } 

हाँ टन अनुप्रयोगों! क्या मुझे आपको जेनरिक के बारे में बताना चाहिए?

5. नाम स्थान

वे वहां भी नहीं हैं। जब सिस्टम में प्रकारों की संख्या डेढ़ सौ से अधिक हो जाती है, तो नाम टकराने की संभावना एक सौ प्रतिशत हो जाती है।

और सभी प्रकार के Service_GuideNDriving_Standard_Model_Input दिखाई देते हैं। मैं अलग-अलग समापन बिंदुओं पर पूर्ण नामस्थानों के बारे में बात नहीं कर रहा हूं, जैसे SOAP (हाँ, हाँ, यह भयानक है, लेकिन नामस्थान पूरी तरह से बने हैं)। और योजनाओं के बीच "गड़गड़ाहट" प्रकार की क्षमता के साथ एक समापन बिंदु पर कम से कम कई योजनाएं।

कुल मिलाकर

GraphQL एक अच्छा उपकरण है। यह पूरी तरह से एक सहिष्णु, सूक्ष्मदर्शी वास्तुकला पर फिट बैठता है, जो उन्मुख है, सबसे पहले, सूचना आउटपुट और सरल, निर्धारक इनपुट।

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

ग्रेफ्ल वास्तव में (और कभी-कभी बिल्कुल नहीं ) सीआरयूडी के बारे में नहीं है।

लेकिन इसका मतलब यह नहीं है कि आप इसे खा नहीं सकते :)

अगले लेख में, मैं ऊपर वर्णित कुछ समस्याओं के साथ कैसे लड़ना चाहता हूं (और कभी-कभी सफलतापूर्वक) के बारे में बात करना चाहता हूं।