অবিলম্বে প্রতিক্রিয়া আপনার উপায় প্রবাহ

যে কেউ পরিষেবা কর্মী ব্যবহার করেছে তারা আপনাকে বলতে পারে যে তারা সমস্ত পথ অসিঙ্ক্রোনাস। তারা একচেটিয়াভাবে ইভেন্ট-ভিত্তিক ইন্টারফেসের উপর নির্ভর করে, যেমন FetchEvent , এবং অ্যাসিঙ্ক্রোনাস অপারেশন সম্পূর্ণ হলে সংকেত দেওয়ার প্রতিশ্রুতি ব্যবহার করে।

অ্যাসিঙ্ক্রোনিসিটি সমানভাবে গুরুত্বপূর্ণ, যদিও ডেভেলপারের কাছে কম দৃশ্যমান হয়, যখন এটি কোনও পরিষেবা কর্মীর ফেচ ইভেন্ট হ্যান্ডলার দ্বারা প্রদত্ত প্রতিক্রিয়াগুলির ক্ষেত্রে আসে৷ স্ট্রিমিং প্রতিক্রিয়াগুলি এখানে সোনার মানদণ্ড: তারা যে পৃষ্ঠাটি প্রথম অনুরোধটি ডেটার প্রথম অংশ উপলব্ধ হওয়ার সাথে সাথে প্রতিক্রিয়ার সাথে কাজ শুরু করার অনুমতি দেয় এবং ক্রমবর্ধমানভাবে বিষয়বস্তু প্রদর্শনের জন্য স্ট্রিমিংয়ের জন্য অপ্টিমাইজ করা পার্সারগুলি ব্যবহার করে।

আপনার নিজের fetch ইভেন্ট হ্যান্ডলার লেখার সময়, আপনি fetch() বা caches.match() এর মাধ্যমে যে প্রতিক্রিয়া পান, শুধুমাত্র respondWith() পদ্ধতিতে একটি Response (বা একটি Response ) পাস করুন এবং এটিকে একটি দিন কল করুন। ভাল খবর হল যে উভয় পদ্ধতির দ্বারা তৈরি Response ইতিমধ্যেই স্ট্রিমযোগ্য! খারাপ খবর হল "ম্যানুয়ালি" তৈরি করা Response স্ট্রিমযোগ্য নয়, অন্তত এখন পর্যন্ত। সেখানেই স্ট্রীমস এপিআই ছবিটিতে প্রবেশ করে।

প্রবাহ?

একটি স্ট্রীম একটি ডেটা উত্স যা ক্রমবর্ধমানভাবে তৈরি এবং ম্যানিপুলেট করা যেতে পারে এবং ডেটার অসিঙ্ক্রোনাস খণ্ডগুলি পড়ার বা লেখার জন্য একটি ইন্টারফেস সরবরাহ করে, যার শুধুমাত্র একটি উপসেট যে কোনও নির্দিষ্ট সময়ে মেমরিতে উপলব্ধ হতে পারে। আপাতত, আমরা ReadableStream s- এ আগ্রহী, যা fetchEvent.respondWith() এ পাস করা একটি Response অবজেক্ট তৈরি করতে ব্যবহার করা যেতে পারে :

self.addEventListener('fetch', event => {
    var stream = new ReadableStream({
    start(controller) {
        if (/* there's more data */) {
        controller.enqueue(/* your data here */);
        } else {
        controller.close();
        }
    });
    });

    var response = new Response(stream, {
    headers: {'content-type': /* your content-type here */}
    });

    event.respondWith(response);
});

যে পৃষ্ঠার অনুরোধটি ইভেন্ট fetch ট্রিগার করেছে event.respondWith() কল করার সাথে সাথেই একটি স্ট্রিমিং প্রতিক্রিয়া ফিরে পাবে এবং যতক্ষণ পর্যন্ত পরিষেবা কর্মী অতিরিক্ত ডেটা enqueue() চালিয়ে যাবে ততক্ষণ এটি সেই স্ট্রিম থেকে পড়া চালিয়ে যাবে৷ পরিষেবা কর্মী থেকে পৃষ্ঠায় প্রবাহিত প্রতিক্রিয়া সত্যিই অসিঙ্ক্রোনাস, এবং স্ট্রীমটি পূরণ করার উপর আমাদের সম্পূর্ণ নিয়ন্ত্রণ আছে!

বাস্তব-বিশ্ব ব্যবহার করে

আপনি সম্ভবত লক্ষ্য করেছেন যে পূর্ববর্তী উদাহরণে কিছু স্থানধারক /* your data here */ মন্তব্য ছিল, এবং বাস্তব বাস্তবায়নের বিবরণের উপর হালকা ছিল। তাই একটি বাস্তব বিশ্বের উদাহরণ দেখতে কেমন হবে?

জেক আর্চিবল্ড (আশ্চর্যজনক নয়!) একাধিক ক্যাশ করা এইচটিএমএল স্নিপেট থেকে একটি এইচটিএমএল প্রতিক্রিয়া একসাথে সেলাই করার জন্য স্ট্রিম ব্যবহার করার একটি দুর্দান্ত উদাহরণ রয়েছে, সাথে fetch() এর মাধ্যমে স্ট্রিম করা "লাইভ" ডেটা - এই ক্ষেত্রে, তার ব্লগের সামগ্রী

একটি স্ট্রিমিং প্রতিক্রিয়া ব্যবহার করার সুবিধা, যেমন জেক ব্যাখ্যা করেছেন , ব্রাউজারটি সম্পূর্ণ ব্লগ সামগ্রী আনার জন্য অপেক্ষা না করে, ক্যাশে থেকে দ্রুত লোড হওয়া প্রাথমিক বিট সহ, স্ট্রিম করার সাথে সাথে HTML কে পার্স এবং রেন্ডার করতে পারে৷ এটি ব্রাউজারের প্রগতিশীল HTML রেন্ডারিং ক্ষমতার পূর্ণ সুবিধা নেয়। কিছু ইমেজ এবং ভিডিও ফরম্যাটের মতো ক্রমবর্ধমানভাবে রেন্ডার করা যেতে পারে এমন অন্যান্য সংস্থানগুলিও এই পদ্ধতি থেকে উপকৃত হতে পারে।

প্রবাহ? নাকি অ্যাপ শেল?

আপনার ওয়েব অ্যাপ্লিকেশানগুলিকে শক্তিশালী করতে পরিষেবা কর্মীদের ব্যবহার করার জন্য বিদ্যমান সেরা অনুশীলনগুলি একটি অ্যাপ শেল + ডায়নামিক সামগ্রী মডেলের উপর ফোকাস করে৷ এই পদ্ধতিটি আপনার ওয়েব অ্যাপ্লিকেশনের "শেল" কে আক্রমনাত্মকভাবে ক্যাশ করার উপর নির্ভর করে—আপনার কাঠামো এবং বিন্যাস প্রদর্শনের জন্য প্রয়োজনীয় ন্যূনতম HTML, জাভাস্ক্রিপ্ট এবং CSS-এবং তারপর ক্লায়েন্ট-সাইড অনুরোধের মাধ্যমে প্রতিটি নির্দিষ্ট পৃষ্ঠার জন্য প্রয়োজনীয় গতিশীল সামগ্রী লোড করা।

স্ট্রীমগুলি তাদের সাথে অ্যাপ শেল মডেলের একটি বিকল্প নিয়ে আসে, যেখানে ব্যবহারকারী একটি নতুন পৃষ্ঠায় নেভিগেট করলে ব্রাউজারে একটি পূর্ণ HTML প্রতিক্রিয়া স্ট্রিম করা হয়। স্ট্রীম করা প্রতিক্রিয়া ক্যাশে করা সম্পদ ব্যবহার করতে পারে—তাই এটি এখনও অফলাইনে থাকাকালীনও দ্রুত HTML-এর প্রাথমিক অংশ প্রদান করতে পারে!—কিন্তু তারা শেষ পর্যন্ত প্রথাগত, সার্ভার-রেন্ডার করা প্রতিক্রিয়া সংস্থার মতো দেখায়৷ উদাহরণ স্বরূপ, যদি আপনার ওয়েব অ্যাপটি একটি বিষয়বস্তু ব্যবস্থাপনা সিস্টেম দ্বারা চালিত হয় যা সার্ভার-রেন্ডার করে HTML-কে আংশিক টেমপ্লেট একসাথে সেলাই করে, সেই মডেলটি সরাসরি স্ট্রিমিং প্রতিক্রিয়া ব্যবহার করে অনুবাদ করে, টেমপ্লেটিং লজিক আপনার সার্ভারের পরিবর্তে পরিষেবা কর্মীতে প্রতিলিপি করা হয়। নিম্নলিখিত ভিডিওটি দেখায় যে, ব্যবহারের ক্ষেত্রে, গতির সুবিধা যা স্ট্রিম করা প্রতিক্রিয়াগুলি অফার করে তা আকর্ষণীয় হতে পারে:

পুরো এইচটিএমএল প্রতিক্রিয়া স্ট্রিম করার একটি গুরুত্বপূর্ণ সুবিধা, ব্যাখ্যা করে কেন এটি ভিডিওতে সবচেয়ে দ্রুত বিকল্প, প্রাথমিক নেভিগেশন অনুরোধের সময় রেন্ডার করা HTML ব্রাউজারের স্ট্রিমিং HTML পার্সারের সম্পূর্ণ সুবিধা নিতে পারে। পৃষ্ঠাটি লোড হওয়ার পরে একটি নথিতে HTML-এর অংশগুলি ঢোকানো হয় (যেমনটি অ্যাপ শেল মডেলে সাধারণ) এই অপ্টিমাইজেশনের সুবিধা নিতে পারে না।

সুতরাং আপনি যদি আপনার পরিষেবা কর্মী বাস্তবায়নের পরিকল্পনার পর্যায়ে থাকেন, তাহলে আপনার কোন মডেলটি গ্রহণ করা উচিত: স্ট্রিম করা প্রতিক্রিয়া যা ক্রমান্বয়ে রেন্ডার করা হয়, অথবা গতিশীল সামগ্রীর জন্য ক্লায়েন্ট-সাইড অনুরোধের সাথে একটি হালকা শেল? উত্তর হল, আশ্চর্যজনক নয় যে এটি নির্ভর করে: আপনার কাছে একটি বিদ্যমান বাস্তবায়ন আছে কিনা যা একটি CMS এবং আংশিক টেমপ্লেটের উপর নির্ভর করে (সুবিধা: স্ট্রিম); আপনি একক, বড় এইচটিএমএল পেলোড আশা করছেন কিনা যা প্রগতিশীল রেন্ডারিং থেকে উপকৃত হবে (সুবিধা: স্ট্রীম); আপনার ওয়েব অ্যাপটি একটি একক-পৃষ্ঠার অ্যাপ্লিকেশন হিসাবে সেরা মডেল করা হয়েছে কিনা তা নিয়ে (সুবিধা: অ্যাপ শেল); এবং আপনার এমন একটি মডেল দরকার যা বর্তমানে একাধিক ব্রাউজারের স্থিতিশীল রিলিজ জুড়ে সমর্থিত (সুবিধা: অ্যাপ শেল)।

আমরা এখনও পরিষেবা কর্মী-চালিত স্ট্রিমিং প্রতিক্রিয়াগুলির খুব প্রাথমিক দিনগুলিতে রয়েছি, এবং আমরা বিভিন্ন মডেলগুলি পরিপক্ক দেখতে এবং বিশেষত সাধারণ ব্যবহারের ক্ষেত্রে স্বয়ংক্রিয় করার জন্য আরও টুলিং তৈরি দেখার অপেক্ষায় রয়েছি।

স্রোতের গভীরে ডুব দিচ্ছে

আপনি যদি আপনার নিজস্ব পঠনযোগ্য স্ট্রীম তৈরি করেন, তাহলে নির্বিচারে controller.enqueue() কল করা যথেষ্ট বা কার্যকর নাও হতে পারে। জেক কিভাবে start() , pull() , এবং cancel() পদ্ধতিগুলিকে আপনার ব্যবহারের ক্ষেত্রে উপযোগী করে একটি ডেটা স্ট্রীম তৈরি করতে ব্যবহার করা যেতে পারে সে সম্পর্কে কিছু বিশদ বিবরণ দেন

যারা আরও বিস্তারিত জানতে চান তাদের জন্য, স্ট্রিম স্পেসিফিকেশন আপনাকে কভার করেছে।

সামঞ্জস্য

একটি ReadableStream ব্যবহার করে একটি পরিষেবা কর্মীর ভিতরে একটি Response অবজেক্ট তৈরি করার জন্য সমর্থন কারণ এটির উৎস Chrome 52 এ যোগ করা হয়েছে।

Firefox-এর পরিষেবা কর্মী বাস্তবায়ন এখনও ReadableStream s দ্বারা সমর্থিত প্রতিক্রিয়াগুলিকে সমর্থন করে না, তবে স্ট্রীমস API সমর্থনের জন্য একটি প্রাসঙ্গিক ট্র্যাকিং বাগ রয়েছে যা আপনি অনুসরণ করতে পারেন৷

এজ-এ আনপ্রিফিক্সড স্ট্রীমস API সমর্থনের অগ্রগতি, সামগ্রিক পরিষেবা কর্মী সমর্থন সহ, Microsoft-এর প্ল্যাটফর্ম স্থিতি পৃষ্ঠায় ট্র্যাক করা যেতে পারে।