14 हेडलेस सेमी 2019 की समीक्षा

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

एक सिर रहित सीएमएस क्या है?

हालाँकि यह शब्द नया नहीं है, लेकिन किसी कारणवश यह विषय रूसी भाषा के इंटरनेट में बहुत कम है। तो विकिपीडिया के अनुसार:

एक हेडलेस कंटेंट मैनेजमेंट सिस्टम , या हेडलेस सीएमएस , एक बैक-एंड ओनली कंटेंट मैनेजमेंट सिस्टम (CMS) है, जो किसी भी डिवाइस पर डिस्प्ले के लिए RESTful API के माध्यम से कंटेंट को एक्सेस करने वाली सामग्री रिपॉजिटरी के रूप में जमीन से निर्मित होता है।
हेडलेस कंटेंट मैनेजमेंट सिस्टम या हेडलेस सीएमएस एक सर्वर-आधारित कंटेंट मैनेजमेंट सिस्टम (CMS) है, जो शुरू में कंटेंट का भंडार होता है और किसी भी डिवाइस पर डिस्प्ले के लिए RESTful API के माध्यम से कंटेंट तक पहुंच प्रदान करता है।

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

आप इस लेख में इस तरह के अवधारणा के पेशेवरों और विपक्षों के बारे में अधिक पढ़ सकते हैं, या यह एक , या फिर विकिपीडिया लेख में ।

प्रसंग में डूबना

खोज मानदंड निर्धारित करने और यह समझने के लिए कि कौन सी हेडलेस सेमी दूसरों की तुलना में बेहतर है, मुझे इस सवाल का जवाब देना था - सबसे अच्छा क्या है? इसे किस विशिष्ट कार्य को हल करना चाहिए और कैसे?

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

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

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

ये वे आवश्यकताएं हैं जो एक आंतरिक ग्राहक से आई हैं। कार्यान्वयन के लिए विकास पक्ष की अपनी तकनीकी दृष्टि है, अर्थात्:

• ग्राहक को अपने घुटने को गोली मारने में सक्षम नहीं होना चाहिए, अर्थात्। सामग्री प्रबंधक को कुछ भी नहीं तोड़ना चाहिए, भले ही वह चाहे। इसे केवल वही संपादित करना चाहिए जो डेवलपर्स ने कल्पना की थी;
• अगर कुछ होता है तो संस्करण प्रबंधित करने और वापस रोल करने में सक्षम होना चाहिए;
• यह ज्ञात नहीं है कि भविष्य में अतिरिक्त कार्यक्षमता क्या दिखाई देगी, जिसका अर्थ है कि किसी अनुभाग को जटिल या बदलना आसान होना चाहिए;
• सुरक्षा पक्ष पर: सिस्टम हमारे सर्वर पर होना चाहिए, और एक अजीब बादल में नहीं, अर्थात। परिसर में तैनात करने में सक्षम होना चाहिए।

खैर, कार्य स्पष्ट है। मैं फैसले के पास जाता हूं।

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

पहली बात यह है कि मॉडल का वर्णन करना है। मॉडल प्रश्न का उत्तर देता है, सामग्री इकाई को कैसा दिखना चाहिए? उसकी संरचना क्या है? संक्षेप में, यह सेमी और क्लाइंट एप्लिकेशन के बीच सहभागिता का एक प्रोटोकॉल है। हमारे मामले में - फिल्म की समीक्षा - वस्तु में शामिल हैं:

• 3 अनिवार्य गुण: फिल्म का शीर्षक, फिल्म का पोस्टर, समीक्षा पाठ;
• 1 वैकल्पिक संपत्ति: ऑब्जेक्ट "निर्देशक", जिसमें बदले में 2 आवश्यक गुण नाम और उपनाम शामिल हैं।

JSON स्कीमा दृश्य मॉडल में ऐसा दिखता है:

{ type: 'object', required: ['movieName', 'moviePoster', 'reviewText'], additionalProperties: false, properties: { movieName: { type: 'string', minLength: 1, maxLength: 300, }, moviePoster: { type: 'string', description: 'URL to file', }, movieProducer: { type: 'object', required: ['name', 'surname'], additionalProperties: false, properties: { name: { type: 'string', maxLength: 100, minLength: 1 }, surname: { type: 'string', maxLength: 100, minLength: 1 }, }, }, reviewText: { type: 'string', minLength: 1, maxLength: 3000, }, }, } 

आपको टॉगल सुविधा लागू करने की भी आवश्यकता है, JSON स्कीमा के रूप में एक मॉडल इस तरह दिखता है:

 { type: 'object', required: ['isFeatureActive', 'name'], additionalProperties: false, properties: { isFeatureActive: { type: 'boolean' }, name: { type: 'string', enum: ['movieReviewFeatureToggle'] }, }, } 

जब आपको यह समझना होगा कि मॉडल कैसे दिखना चाहिए, तो आप उन्हें किसी भी JSON CMS में बना सकते हैं।



मैं तुरंत सामग्री संस्थाएँ बनाता हूँ, अर्थात् सामग्री ही, मॉडल के आधार पर। एक डमी समीक्षा और सुविधा टॉगल इकाई।



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


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

 import React, { Component } from 'react' import { Accordion, AccordionItem, AccordionItemTitle, AccordionItemBody, } from 'react-accessible-accordion' import 'react-accessible-accordion/dist/fancy-example.css' const apiUrl = 'https://api.anyjsoncms.com' // ApiKey      const apiKey = '87414950dfd15648ea560bd89dd0ee02bfc8fcca' class App extends Component { constructor(props) { super(props) this.state = { movies: null, isFeatureActive: null, loading: true, } } componentDidMount() { const options = { method: 'GET', headers: { ApiKey: apiKey } } Promise.all([ fetch(`${apiUrl}/entries?apiId=featureToggle`, options).then(resp => resp.json() ), fetch(`${apiUrl}/entries?apiId=movieReview`, options).then(resp => resp.json() ), ]) .then(([featureToggleResp, movieReviewResp]) => { const featureToggle = featureToggleResp.find( item => item.value.name === 'movieReviewFeatureToggle' ) const isFeatureActive = featureToggle && featureToggle.value && featureToggle.value.isFeatureActive const movies = movieReviewResp.map(item => item.value) this.setState({ movies, isFeatureActive, loading: false }) }) .catch(error => { console.error(error) }) } render() { const { movies, isFeatureActive, loading } = this.state if (loading) return <div>Loading...</div> if (!isFeatureActive) return <div style={{ display: 'none' }}>Section is hidden</div> return ( <div> <Accordion> {movies.map( ({ movieName, moviePoster, movieProducer, reviewText }, index) => ( <AccordionItem key={index}> <AccordionItemTitle> <h3>{movieName}</h3> </AccordionItemTitle> <AccordionItemBody> <img src={`${apiUrl}${moviePoster}`} alt="" /> {!movieProducer ? null : ( <div>{`${movieProducer.name} ${ movieProducer.surname }`}</div> )} <div>{reviewText}</div> </AccordionItemBody> </AccordionItem> ) )} </Accordion> </div> ) } } export default App 

वह सब है। अब सामग्री प्रबंधक आसानी से समीक्षाओं का प्रबंधन कर सकता है, और सुविधा टॉगल का उपयोग करके कार्यक्षमता को सक्षम और अक्षम करने का अवसर भी है।

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

चयन मानदंड और विश्लेषण हेडलेस सेमी

चूंकि मुझे इस बात की समझ थी कि हेडलेस सेमी का उपयोग करके क्या कार्य हल किए जाएंगे और कैसे, मैंने मापदंड का चयन किया और प्रणालियों का अध्ययन करना शुरू किया। वर्तमान में headlesscms.org के अनुसार 54 सेमी हैं। उन सभी का विश्लेषण एक समय लेने वाली प्रक्रिया है, इसलिए मैंने 14 सबसे लोकप्रिय, उल्लेखनीय और चर्चा की गई प्रणालियों पर प्रकाश डाला: कोई भी JSON CMS, कंटेंटफुल, Strapi, GraphCMS, Squidex, Butter CMS, Cloud CMS, ockpit, Cosmic JS, Directus, Kentico Cloud, Netlify CMS , प्रिज़्मिक, भूत।

परिणाम तालिका के रूप में अध्ययन करने के लिए अधिक सुविधाजनक हैं। लेकिन यहाँ नकल।

कोई JSON सीएमएस

Contentful

Strapi

GraphCMS

Squidex

मक्खन सी.एम.

मेघ सी.एम.

Sockpit

Cosmic JS

Directus

Kentico Cloud

Netlify CMS

Prismic

Ghost

निष्कर्ष

headless cms : , , git , .
. , . , , , , , , — . :

• headless cms . , , . , , , , . , , . - Cloud CMS, Cockpit Cosmic JS.
• : , , . , - , — . , - , :
  

   { "oneOf": [ { "type": "number", "multipleOf": 5 }, { "type": "number", "multipleOf": 3 } ] } 

  
  Cockpit.
  
• , . , number, 100. , maximum: 50? ? GraphCMS.
• Git Cloud CMS Netlify CMS.

, , . Cloud CMS, .

निष्कर्ष

, headless cms. , . Any JSON CMS .

UPDATE: Any JSON CMS open source , github .

— git . , , “” .