पिछले हफ्ते, हमने अपने छोटे डेमो प्रोजेक्ट, चिंराट के बारे में बात की , जो स्पष्ट रूप से दिखाता है कि आप कम या ज्यादा समान परिस्थितियों में C ++ पुस्तकालयों Restinio और SObjectizer का उपयोग कैसे कर सकते हैं। झींगा एक छोटा C ++ 17 एप्लिकेशन है, जो Restinio के माध्यम से, इमेज स्केलिंग के लिए HTTP अनुरोध स्वीकार करता है और इन अनुरोधों को SObjectizer और ImageMagick ++ के माध्यम से मल्टी-थ्रेडेड मोड में कार्य करता है।

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

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

v0.3: समान अनुरोधों के समानांतर प्रसंस्करण का नियंत्रण

पिछले लेख में वर्णित झींगा के पहले संस्करण में एक गंभीर सरलीकरण शामिल था: इस बात पर कोई नियंत्रण नहीं था कि वर्तमान में उसी अनुरोध को संसाधित किया जा रहा है या नहीं।

कल्पना करें कि पहली बार झींगा को "/demo.jpg?op=resize&max=1024" फ़ॉर्म का अनुरोध प्राप्त हुआ है। रूपांतरित छवि कैश में ऐसी कोई छवि अभी तक नहीं है, इसलिए अनुरोध संसाधित किया जा रहा है। प्रसंस्करण में काफी समय लग सकता है, कहते हैं, कुछ सौ मिलीसेकंड।

अनुरोध प्रसंस्करण अभी तक पूरा नहीं हुआ है, और झींगा को फिर से एक ही अनुरोध "/demo.jpg?op=resize&max=1024" प्राप्त होता है, लेकिन दूसरे ग्राहक से। कैश में कोई परिवर्तन परिणाम अभी तक नहीं है, इसलिए इस अनुरोध को भी संसाधित किया जाएगा।

न तो पहला और न ही दूसरा अनुरोध अभी तक पूरा नहीं हुआ है, और झींगा फिर से एक ही अनुरोध प्राप्त कर सकता है "/demo.jpg?op=resize&max=1024"। और इस अनुरोध पर भी कार्रवाई की जाएगी। यह पता चला है कि समान चित्र को समान आकार में कई बार स्केल किया जाता है।

यह अच्छा नहीं है। इसलिए, हमने पहली चीज़ जो चिंराट पर तय की थी, वह इस तरह के गंभीर जाम से छुटकारा पाने के लिए थी। हमने ट्रांसफॉर्म_मनजर एजेंट में दो मुश्किल कंटेनरों के कारण ऐसा किया। पहला कंटेनर मुफ्त ट्रांसफार्मर अनुरोधों की प्रतीक्षा की एक कतार है। यह एक कंटेनर है जिसका नाम m_pending_requests है। दूसरे कंटेनर स्टोर अनुरोध जो पहले ही संसाधित हो चुके हैं (यानी इन अनुरोधों के लिए विशिष्ट ट्रांसफार्मर आवंटित किए गए थे)। यह एक कंटेनर है जिसका नाम m_inprogress_requests है।

जब ट्रांसफार्म_मनगर को अगला अनुरोध प्राप्त होता है, तो वह परिवर्तित छवियों की कैश में तैयार छवि की उपस्थिति की जांच करता है। यदि कोई रूपांतरित चित्र नहीं है, तो m_inprogress_requests और m_pending_requests कंटेनरों की जाँच की जाती है। और अगर इन कंटेनरों में ऐसे मापदंडों के साथ कोई अनुरोध नहीं है, तो केवल अनुरोध को m_pending_requests कतार में रखने का प्रयास किया जाता है। यह इस तरह दिखता है :

void a_transform_manager_t::handle_not_transformed_image( transform::resize_request_key_t request_key, sobj_shptr_t<resize_request_t> cmd ) { const auto store_to = [&](auto & queue) { queue.insert( std::move(request_key), std::move(cmd) ); }; if( m_inprogress_requests.has_key( request_key ) ) { //    . //         . store_to( m_inprogress_requests ); } else if( m_pending_requests.has_key( request_key ) ) { //      . store_to( m_pending_requests ); } else if( m_pending_requests.unique_keys() < max_pending_requests ) { //           . store_to( m_pending_requests ); //    transformer-     . try_initiate_pending_requests_processing(); } else { //  ,   . do_503_response( std::move(cmd->m_http_req) ); } } 

ऊपर कहा गया था कि m_inprogress_requests और m_pending_requests मुश्किल कंटेनर हैं। लेकिन चाल क्या है?

चाल यह है कि ये कंटेनर एक नियमित FIFO कतार (जिसमें तत्वों को जोड़ने का कालानुक्रमिक क्रम संरक्षित है) और मल्टीमैप, यानी दोनों के गुणों को मिलाते हैं। एक सहयोगी कंटेनर जिसमें कई मानों को एक ही कुंजी पर मैप किया जा सकता है।

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

झींगा में, हमने अपने छोटे कंटेनर को इन उद्देश्यों के लिए साइकिल दिया। हालांकि, अगर झींगा में बूस्ट का इस्तेमाल किया गया था, तो Boost.MultiIndex का इस्तेमाल किया जा सकता है। और, शायद, समय के साथ, m_pending_requests में एक प्रभावी खोज को कुछ अन्य मानदंडों द्वारा व्यवस्थित करने की आवश्यकता होगी, फिर चिंराट में Boost.MultiIndex को सक्रिय करना होगा।

v0.4: spdlog के साथ लॉगिंग

हमने श्रिंप के पहले संस्करण को यथासंभव सरल और कॉम्पैक्ट छोड़ने की कोशिश की। किस वजह से, चिंराट के पहले संस्करण में, हमने लॉगिंग का उपयोग नहीं किया। आम तौर पर।

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

उदाहरण के लिए, लॉगिंग के साथ handle_not_transformed_image () विधि का उपरोक्त कोड कुछ इस तरह दिखाई देने लगता है:

 void a_transform_manager_t::handle_not_transformed_image( transform::resize_request_key_t request_key, sobj_shptr_t<resize_request_t> cmd ) { const auto store_to = [&](auto & queue) { queue.insert( std::move(request_key), std::move(cmd) ); }; if( m_inprogress_requests.has_key( request_key ) ) { //    . m_logger->debug( "same request is already in progress; request_key={}", request_key ); //         . store_to( m_inprogress_requests ); } else if( m_pending_requests.has_key( request_key ) ) { //      . m_logger->debug( "same request is already pending; request_key={}", request_key ); store_to( m_pending_requests ); } else if( m_pending_requests.unique_keys() < max_pending_requests ) { //           . m_logger->debug( "store request to pending requests queue; request_key={}", request_key ); store_to( m_pending_requests ); //    transformer-     . try_initiate_pending_requests_processing(); } else { //  ,   . m_logger->warn( "request is rejected because of overloading; " "request_key={}", request_key ); do_503_response( std::move(cmd->m_http_req) ); } } 

Spdlog लॉगर कॉन्फ़िगर करना

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

 //     . [[nodiscard]] spdlog::sink_ptr make_logger_sink() { auto sink = std::make_shared< spdlog::sinks::ansicolor_stdout_sink_mt >(); return sink; } [[nodiscard]] std::shared_ptr<spdlog::logger> make_logger( const std::string & name, spdlog::sink_ptr sink, spdlog::level::level_enum level = spdlog::level::trace ) { auto logger = std::make_shared< spdlog::logger >( name, std::move(sink) ); logger->set_level( level ); logger->flush_on( level ); return logger; } //        : auto manager = coop.make_agent_with_binder< a_transform_manager_t >( create_one_thread_disp( "manager" )->binder(), make_logger( "manager", logger_sink ) ); ... const auto worker_name = fmt::format( "worker_{}", worker ); auto transformer = coop.make_agent_with_binder< a_transformer_t >( create_one_thread_disp( worker_name )->binder(), make_logger( worker_name, logger_sink ), app_params.m_storage ); 

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

इस तथ्य के कारण कि झींगा में प्रत्येक इकाई का अपना नाम के साथ अपना लकड़हारा है, हम देख सकते हैं कि लॉग में कौन क्या करता है:

Spblog के साथ Trabing SObjectizer

लॉगिंग बार, जो कि SObjectizer एप्लिकेशन के मुख्य व्यवसाय तर्क के भाग के रूप में किए जाते हैं, एप्लिकेशन को डीबग करने के लिए पर्याप्त नहीं हैं। यह स्पष्ट नहीं है कि एक एजेंट में कुछ कार्रवाई क्यों शुरू की जाती है, लेकिन वास्तव में किसी अन्य एजेंट में प्रदर्शन नहीं किया जाता है। इस मामले में, SObjectizer में निर्मित msg_tracing तंत्र बहुत मदद करता है (जो हमने एक अलग लेख में बात की थी)। लेकिन SObjectizer के लिए मानक msg_tracing कार्यान्वयन के बीच, spdlog का उपयोग करने वाला कोई भी नहीं है। हम इस कार्यान्वयन को स्वयं झींगा के लिए करेंगे:

 class spdlog_sobj_tracer_t : public so_5::msg_tracing::tracer_t { std::shared_ptr<spdlog::logger> m_logger; public: spdlog_sobj_tracer_t( std::shared_ptr<spdlog::logger> logger ) : m_logger{ std::move(logger) } {} virtual void trace( const std::string & what ) noexcept override { m_logger->trace( what ); } [[nodiscard]] static so_5::msg_tracing::tracer_unique_ptr_t make( spdlog::sink_ptr sink ) { return std::make_unique<spdlog_sobj_tracer_t>( make_logger( "sobjectizer", std::move(sink) ) ); } }; 

यहाँ हम विशेष SObjectizer इंटरफ़ेस tracer_t के कार्यान्वयन को देखते हैं, जिसमें मुख्य बात वर्चुअल ट्रेस () विधि है। यह वह है जो Spdlog टूल का उपयोग करके SObjectizer के आंतरिक भाग का अनुरेखण करता है।

अगला, यह कार्यान्वयन SObjectizer शुरू करते समय ट्रैसर के रूप में स्थापित होता है:

 so_5::wrapped_env_t sobj{ [&]( so_5::environment_t & env ) {...}, [&]( so_5::environment_params_t & params ) { if( sobj_tracing_t::on == sobj_tracing ) params.message_delivery_tracer( spdlog_sobj_tracer_t::make( logger_sink ) ); } }; 

रिस्टिनियो ट्रेसलॉग के माध्यम से

SObjectizer के अंदर क्या होता है, इसे ट्रेस करने के अलावा, Restinio के अंदर क्या होता है, इसे ट्रेस करना कई बार बहुत उपयोगी हो सकता है। झींगा के अद्यतन संस्करण में, इस तरह के एक ट्रेस को भी जोड़ा जाता है।

यह ट्रेस एक विशेष वर्ग की परिभाषा के माध्यम से कार्यान्वित किया जाता है जो Restinio में लॉगिंग कर सकता है:

 class http_server_logger_t { public: http_server_logger_t( std::shared_ptr<spdlog::logger> logger ) : m_logger{ std::move( logger ) } {} template< typename Builder > void trace( Builder && msg_builder ) { log_if_enabled( spdlog::level::trace, std::forward<Builder>(msg_builder) ); } template< typename Builder > void info( Builder && msg_builder ) { log_if_enabled( spdlog::level::info, std::forward<Builder>(msg_builder) ); } template< typename Builder > void warn( Builder && msg_builder ) { log_if_enabled( spdlog::level::warn, std::forward<Builder>(msg_builder) ); } template< typename Builder > void error( Builder && msg_builder ) { log_if_enabled( spdlog::level::err, std::forward<Builder>(msg_builder) ); } private: template< typename Builder > void log_if_enabled( spdlog::level::level_enum lv, Builder && msg_builder ) { if( m_logger->should_log(lv) ) { m_logger->log( lv, msg_builder() ); } } std::shared_ptr<spdlog::logger> m_logger; }; 

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

इसके बाद, हमें यह इंगित करना होगा कि HTTP सर्वर http_server_logger_t वर्ग को अपने लकड़हारे के रूप में ऊपर दिखाएगी। यह HTTP सर्वर के गुणों को स्पष्ट करके किया गया है:

 struct http_server_traits_t : public restinio::default_traits_t { using logger_t = http_server_logger_t; using request_handler_t = http_req_router_t; }; 

ठीक है, फिर कुछ भी करने के लिए नहीं बचा है - spd-logger का एक विशिष्ट उदाहरण बनाएं और इस लकड़हारे को बनाए गए HTTP सर्वर पर भेजें:

 auto restinio_logger = make_logger( "restinio", logger_sink, restinio_tracing_t::off == restinio_tracing ? spdlog::level::off : log_level ); restinio::run( asio_io_ctx, shrimp::make_http_server_settings( thread_count.m_io_threads, params, std::move(restinio_logger), manager_mbox_promise.get_future().get() ) ); 

v0.5: परिवर्तित छवि कैश के लिए मजबूर रीसेट

चिंराट को डीबग करने की प्रक्रिया में, एक छोटी सी चीज की खोज की गई थी जो थोड़ी परेशान थी: रूपांतरित छवि कैश की सामग्री को फ्लश करने के लिए, आपको संपूर्ण झींगा को फिर से चालू करना होगा। यह एक तिपहिया प्रतीत होगा, लेकिन अप्रिय।

यदि यह अप्रिय है, तो आपको इस कमी से छुटकारा पाना चाहिए। सौभाग्य से, यह बिल्कुल मुश्किल नहीं है।

सबसे पहले, हम Shrimp में एक और URL परिभाषित करेंगे जिसमें आप HTTP DELETE अनुरोध भेज सकते हैं: "/ कैश"। तदनुसार, हम इस URL पर अपने हैंडलर को लटका देंगे:

 std::unique_ptr< http_req_router_t > make_router( const app_params_t & params, so_5::mbox_t req_handler_mbox ) { auto router = std::make_unique< http_req_router_t >(); add_transform_op_handler( params, *router, req_handler_mbox ); add_delete_cache_handler( *router, req_handler_mbox ); return router; } 

जहाँ add_delete_cache_handler () फ़ंक्शन इस तरह दिखता है:

 void add_delete_cache_handler( http_req_router_t & router, so_5::mbox_t req_handler_mbox ) { router.http_delete( "/cache", [req_handler_mbox]( auto req, auto /*params*/ ) { const auto qp = restinio::parse_query( req->header().query() ); auto token = qp.get_param( "token"sv ); if( !token ) { return do_403_response( req, "No token provided\r\n" ); } // Delegate request processing to transform_manager. so_5::send< so_5::mutable_msg<a_transform_manager_t::delete_cache_request_t> >( req_handler_mbox, req, restinio::cast_to<std::string>(*token) ); return restinio::request_accepted(); } ); } 

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

दूसरे, हम नए संदेश हैंडलर delete_cache_request_t को transform_manager_t एजेंट में लागू करते हैं:

 void a_transform_manager_t::on_delete_cache_request( mutable_mhood_t<delete_cache_request_t> cmd ) { m_logger->warn( "delete cache request received; " "connection_id={}, token={}", cmd->m_http_req->connection_id(), cmd->m_token ); const auto delay_response = [&]( std::string response_text ) { so_5::send_delayed< so_5::mutable_msg<negative_delete_cache_response_t> >( *this, std::chrono::seconds{7}, std::move(cmd->m_http_req), std::move(response_text) ); }; if( const char * env_token = std::getenv( "SHRIMP_ADMIN_TOKEN" ); // Token must be present and must not be empty. env_token && *env_token ) { if( cmd->m_token == env_token ) { m_transformed_cache.clear(); m_logger->info( "cache deleted" ); do_200_plaintext_response( std::move(cmd->m_http_req), "Cache deleted\r\n" ); } else { m_logger->error( "invalid token value for delete cache request; " "token={}", cmd->m_token ); delay_response( "Token value mismatch\r\n" ); } } else { m_logger->warn( "delete cache can't performed because there is no " "admin token defined" ); // Operation can't be performed because admin token is not avaliable. delay_response( "No admin token defined\r\n" ); } } 

यहां दो बिंदु हैं जिन्हें स्पष्ट किया जाना चाहिए।

On_delete_cache_request () के कार्यान्वयन में पहला बिंदु स्वयं टोकन मूल्य का सत्यापन है। प्रशासनिक टोकन SHRIMP_ADMIN_TOKEN पर्यावरण चर के माध्यम से सेट किया गया है। यदि यह चर सेट किया गया है और इसका मान HTTP DELETE अनुरोध के टोकन पैरामीटर से मूल्य से मेल खाता है, तो कैश को साफ़ कर दिया जाता है और अनुरोध पर एक सकारात्मक प्रतिक्रिया तुरंत उत्पन्न होती है।

और on_delete_cache_request () के कार्यान्वयन में दूसरा बिंदु HTTP DELETE को नकारात्मक प्रतिक्रिया के लिए मजबूर विलंब है। यदि प्रशासनिक टोकन का गलत मूल्य आ गया है, तो आपको HTTP DELETE की प्रतिक्रिया में देरी करनी चाहिए, ताकि क्रूर बल द्वारा टोकन के मूल्य का चयन करने की कोई इच्छा न हो। लेकिन यह देरी कैसे करें? आखिरकार, std :: thread :: sleep_for () को कॉल करना कोई विकल्प नहीं है।

यह वह जगह है जहां SObjectizer के लंबित संदेश बचाव के लिए आते हैं। तुरंत on_delete_cache_request () के अंदर एक नकारात्मक प्रतिक्रिया उत्पन्न करने के बजाय, transform_manager एजेंट केवल खुद को लंबित negative_delete_cache_response_t संदेश भेजता है। SObjectizer टाइमर निर्धारित समय की गणना करेगा और निर्दिष्ट देरी होने के बाद एजेंट को यह संदेश देगा। और अब negative_delete_cache_response_t हैंडलर में, आप पहले से ही HTTP DELETE के अनुरोध पर तुरंत प्रतिक्रिया दे सकते हैं:

 void a_transform_manager_t::on_negative_delete_cache_response( mutable_mhood_t<negative_delete_cache_response_t> cmd ) { m_logger->debug( "send negative response to delete cache request; " "connection_id={}", cmd->m_http_req->connection_id() ); do_403_response( std::move(cmd->m_http_req), std::move(cmd->m_response_text) ); } 

यानी यह निम्नलिखित परिदृश्य को दर्शाता है:

• HTTP सर्वर HTTP DELETE अनुरोध प्राप्त करता है, इस अनुरोध को रूपांतरित करने के लिए एक delete_cache_request_t संदेश में बदल देता है_manager एजेंट;
• transform_manager एजेंट, delete_cache_request_t संदेश प्राप्त करता है और या तो तुरंत अनुरोध के लिए एक सकारात्मक प्रतिक्रिया उत्पन्न करता है या खुद को एक लंबित negative_delete_cache_response_t संदेश भेजता है;
• transform_manager को एक negative_delete_cache_response_t संदेश प्राप्त होता है और वह तुरंत HTTP DELETE अनुरोध के लिए एक नकारात्मक प्रतिक्रिया उत्पन्न करता है।

दूसरे भाग का अंत

दूसरे भाग के अंत में, प्रश्न पूछना बहुत स्वाभाविक है: "आगे क्या?"

इसके अलावा, हमारे डेमो प्रोजेक्ट का संभवतः एक और पुनरावृत्ति और दूसरा अपडेट होगा। मैं एक छवि को एक प्रारूप से दूसरे प्रारूप में परिवर्तित करना चाहता हूं। कहते हैं, सर्वर पर, छवि jpg में है, और परिवर्तन के बाद, इसे क्लाइंट को वेबप में भेजा जाता है।

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

अगर किसी और के पास सुझाव है कि मैं झींगा में या श्रिम्प के आस-पास के लेखों में क्या देखना चाहूंगा, तो हमें किसी भी रचनात्मक विचार को सुनकर खुशी होगी।

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

खैर, और निष्कर्ष में, मैं उन सभी को धन्यवाद देना चाहता हूं जिन्होंने समय लिया और झींगा के दूसरे संस्करण के बारे में बात की, जो कि यहां हैबे और अन्य संसाधनों के माध्यम से है। धन्यवाद!

जारी रखने के लिए ...