সফ্টওয়্যার বিকাশের ক্ষেত্রে আপনি হয়ত REST এর মতো শব্দ শুনেছেন। REST একটি খুব সাধারণভাবে ব্যবহৃত API আর্কিটেকচার, এবং ডেভেলপাররা সফ্টওয়্যার API ডিজাইন করতে এটি ব্যাপকভাবে ব্যবহার করে। অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেসগুলি যে কোনও সফ্টওয়্যার অ্যাপ্লিকেশনের জন্য অত্যাবশ্যক, এবং REST হল অনেকগুলি আর্কিটেকচারের মধ্যে একটি যা API-এর জন্য ব্যবহৃত হয়।
আজকাল, g RPC স্থাপত্য জনপ্রিয়তা অর্জন করছে, এবং এটি REST API s-এর সাথে ঐতিহ্যগতভাবে যুক্ত কিছু সমস্যার সমাধান করারও দাবি করে। কিন্তু তাদের পার্থক্য কোথায়? এবং আপনার আবেদনের জন্য কোনটি ব্যবহার করা উচিত? এই প্রশ্নগুলির উত্তর জানতে, আমাদের g RPC বনাম REST সম্পর্কে আরও বুঝতে হবে এবং কোন পরিস্থিতিতে তারা ভাল পারফর্ম করে। কিন্তু আমরা সে সবের মধ্যে প্রবেশ করার আগে, আসুন দেখি APIগুলি কী এবং তারা মাইক্রোসার্ভিসের জন্য টেবিলে কী নিয়ে আসে।
API কি?
সফ্টওয়্যার অ্যাপগুলি অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস - APIs, যা প্রযুক্তিগত মধ্যস্থতাকারী হিসাবে কাজ করে ব্যবহারের মাধ্যমে একে অপরের সাথে যোগাযোগ এবং যোগাযোগ করতে পারে। একটি API সিস্টেমে ব্যবহারকারীর অনুরোধ পাঠানোর দায়িত্বে থাকে, যা তারপর সিস্টেম থেকে একটি উত্তর পায়।
কল্পনা করুন আপনি অনলাইনে একটি ফোন অর্ডার করছেন। আপনি ওয়েবের সাথে লিঙ্কযুক্ত একটি সাইটে যান এবং এটি একটি সার্ভারে আপনার অনুসন্ধান সম্পর্কে তথ্য পাঠায়৷ সার্ভার তারপর তথ্য পায়, এটি বিশ্লেষণ করে, এবং প্রয়োজনীয় পদক্ষেপ নেওয়ার পরে, আমাদের স্ক্রিনে প্রদর্শিত বিশদ সহ আমাদের কাছে উত্তর দেয়। এটি API এর সাথে সম্ভব হয়।
এপিআই এই ধরনের ক্লায়েন্ট অনুরোধগুলি কীভাবে সম্পাদন করতে হয়, কোন ডেটা স্ট্রাকচার ব্যবহার করতে হবে এবং ক্লায়েন্টদের যে মানগুলি মেনে চলতে হবে তার রূপরেখা দেয়। এটি একটি প্রোগ্রাম অন্যকে যে ধরণের প্রশ্ন পাঠাতে পারে তাও বর্ণনা করে। উভয় g RPC বনাম REST স্থাপত্য শৈলীই API ডিজাইন করার জন্য ব্যাপকভাবে ব্যবহৃত হয়।
API এবং মাইক্রোসার্ভিস
অ্যাপ্লিকেশনগুলির হয় একটি মনোলিথিক আর্কিটেকচার বা একটি মাইক্রোসার্ভিস আর্কিটেকচার থাকতে পারে। সফ্টওয়্যারের সমস্ত ফাংশন এবং মডিউলগুলি একক একক বা কোডবেসে একটি মনোলিথিক অ্যাপ্লিকেশনে থাকে। একটি মাইক্রোসার্ভিস অ্যাপ্লিকেশন, বিপরীতে, অনেক ছোট ইউনিট নিয়ে গঠিত যা HTTP প্রোটোকলের মতো ইন্টারফেসের মাধ্যমে একে অপরের সাথে যোগাযোগ করে।
মনোলিথিক শৈলীর প্রধান সমস্যা হল যে প্রকৌশলীরা পূর্ব-বিদ্যমান ভিত্তির উপরে নতুন ফাংশন এবং পরিষেবা সংযুক্ত করার কারণে সিস্টেমটি পরিবর্তন করা, আপডেট করা এবং প্রসারিত করা কঠিন হয়ে পড়ে। অ্যাপ্লিকেশনের একটি দিকের পরিবর্তন অন্যান্য বিভাগে ক্ষতিকারক প্রভাব ফেলতে পারে। একটি মনোলিথের কোডটি ধীরে ধীরে এমনভাবে জড়িয়ে যায় এবং স্কেল করা, আপডেট করা এবং বহুবার পরিবর্তিত হওয়ার পরে বোঝার জন্য চ্যালেঞ্জিং হয়ে ওঠে যে একটি সম্পূর্ণ সিস্টেম পুনরায় ডিজাইনের প্রয়োজন হয়।
এই সমস্যাটি মাইক্রোসার্ভিস দিয়ে সমাধান করা হয়েছে। এই স্থাপত্য নকশা একটি মনোলিথকে এর উপাদান উপাদানগুলিতে বিভক্ত করে, যার প্রত্যেকটি তারপর একটি পৃথক অ্যাপ্লিকেশন হিসাবে চালিত হয়। এই অ্যাপগুলির প্রতিটিকে একটি মাইক্রোসার্ভিস বলা হয়। তারপর, এই স্বতন্ত্র মাইক্রোসার্ভিসগুলি API ব্যবহার করে সংযোগ করে। APIs দ্বারা সংযুক্ত মাইক্রোসার্ভিসের এই সংগ্রহটি একটি বড় আর্কিটেকচার ডিজাইন তৈরি করতে একত্রিত হয়। APIগুলি একটি মাইক্রোসার্ভিস আর্কিটেকচারে অন্তর্ভুক্ত প্রতিটি উপাদানের মধ্যে সংযোগ এবং যোগাযোগ সক্ষম করে। এপিআই তৈরির কিছু জনপ্রিয় পন্থা হল GraphQL, RPC এবং REST ।
RPC কি?
একটি RPC - রিমোট প্রসিডিউর কল - একটি ওয়েব আর্কিটেকচার যা আপনাকে পূর্বনির্ধারিত ফর্ম ব্যবহার করে একটি রিমোট সার্ভারে একটি পরিষেবা কার্যকর করতে এবং একই বিন্যাসের সাথে একটি প্রতিক্রিয়া পেতে সক্ষম করে৷ সার্ভারের স্টাইল যেটি কোয়েরি সম্পাদন করে, স্থানীয় বা দূরবর্তী সার্ভার, RPC ডিজাইন দ্বারা বিবেচনা করা হয় না।
ছবির উৎস itrelease.com/লেখক জুনায়েদ রেহমান
একটি RPC API অনুরোধের মৌলিক ফাংশন একটি REST API-এর মতোই। RPC API অনুরোধগুলি ইন্টারঅ্যাকশন নির্দেশিকা এবং কৌশলগুলি নির্দিষ্ট করে যা মিথস্ক্রিয়া সম্ভব করে। পরে, ব্যবহারকারী প্যারামিটার ব্যবহার করে এই ফাংশনগুলিকে কল করে। URL-এর অনুরোধ স্ট্রিং-এ কল অপারেশনের জন্য ব্যবহৃত প্যারামিটার থাকে।
API অনুরোধ তৈরি করতে, RPC সিস্টেম একটি ক্লায়েন্ট-সার্ভার কাঠামো ব্যবহার করে। RPC ব্যবহারকারীর অনুরোধ করা তথ্য ব্যাখ্যা করে এবং সার্ভারে প্রেরণ করে। সার্ভারের মধ্যে অভ্যন্তরীণ যোগাযোগ গোপন করা হয়, সার্ভার ব্যবহারকারীর প্রতিক্রিয়া. RPC মডেল একজন ব্যবহারকারীকে একটি নির্দিষ্ট পদ্ধতিতে একটি পরিষেবার জন্য জিজ্ঞাসা করতে সক্ষম করে। RPC এর রয়েছে বিকেন্দ্রীভূত এবং অন-প্রাঙ্গনে উভয় পরিস্থিতিতেই দূরবর্তী পদ্ধতির কল সমর্থন করার সুবিধা।
REST কি?
REST - প্রতিনিধিত্বমূলক রাজ্য স্থানান্তর - একটি ক্লায়েন্ট-সার্ভার আর্কিটেকচারকে বোঝায় যেখানে ব্যবহারকারীরা JSON বা XML যোগাযোগের মাধ্যমে ব্যাকএন্ড তথ্য অ্যাক্সেস করতে পারে। একটি API RESTful বলে বিবেচিত হয় যদি:
- এটির একটি সামঞ্জস্যপূর্ণ ইন্টারফেস রয়েছে এবং API ক্লায়েন্টদের নির্দিষ্ট অ্যাপ সংস্থান সরবরাহ করে।
- সার্ভার এবং ক্লায়েন্ট আলাদাভাবে এবং স্বাধীনভাবে কাজ করে। শুধুমাত্র অ্যাপ্লিকেশনের উপাদানগুলির দিকে নির্দেশ করে এমন URIগুলি ক্লায়েন্টের কাছে পরিচিত হবে৷
- এটি রাষ্ট্রহীন। এর মানে হল যে শুধুমাত্র ক্লায়েন্ট কোন রাষ্ট্রীয় তথ্য সংরক্ষণ করে। সার্ভার ক্লায়েন্ট ক্যোয়ারী সম্পর্কে কোনো রাষ্ট্রীয় তথ্য সংরক্ষণ করবে না।
- API দ্বারা সরবরাহ করা অ্যাপ্লিকেশন সম্পদগুলি অবশ্যই ক্যাশেযোগ্য হতে হবে।
- এটি একটি স্তরযুক্ত স্থাপত্য আছে.
এটি সমসাময়িক আর্কিটেকচারাল ডিজাইনের একটি অ্যাপ্লিকেশন যা হাইপারমিডিয়া নেটওয়ার্কগুলিতে ডেটা ট্রান্সমিশনের অনুমতি দেওয়ার জন্য বিভিন্ন সীমাবদ্ধতার উপর নির্ভর করে। HTTP প্রোটোকল ব্যবহার করে পরিষেবাগুলির সাথে সংযোগ করতে একটি RESTful ওয়েব API URL-এনকোডেড আর্গুমেন্টের প্রয়োজন। স্টেটলেস, এক্সটেনসিবল এবং নির্ভরযোগ্য এপিআই তৈরি করতে সমসাময়িক ওয়েব ডিজাইনে REST API গুলিকে ব্যাপকভাবে গ্রহণ করা হয়েছে।
মাইক্রোসার্ভিস সিস্টেমকে একত্রিত করে এমন প্রতিটি উপাদান ব্যবহারকারী বা গ্রাহকের কাছে একটি সম্পদ হিসাবে প্রদর্শিত হতে পারে যখন REST API সর্বজনীনভাবে অ্যাক্সেসযোগ্য করা হয়। এই সংস্থানটি HTTP GET, POST, PUT এবং DELETE কমান্ড ব্যবহার করে জিজ্ঞাসা করা যেতে পারে।
REST কিভাবে কাজ করে?
API অনুরোধে নির্দিষ্ট করা পরিষেবাগুলির সাথে কাজ করার সময় REST ডিফল্ট যোগাযোগ প্রোটোকল হিসাবে HTTP প্রোটোকল ব্যবহার করে। রিসোর্স এমন একটি জিনিস যা অবজেক্ট-ওরিয়েন্টেড ডিজাইনে একটি বস্তুর সাথে তুলনীয়। RESTful সম্পদের কর্ম এবং বৈশিষ্ট্য রয়েছে, অনেকটা বস্তুর মতো। সাধারণভাবে, REST বাস্তবায়ন সাধারণত RESTful ক্রিয়াগুলির প্রতি কম চিন্তা করে এবং পরিবর্তে একটি সংস্থানের বৈশিষ্ট্যগুলিতে আরও মনোনিবেশ করে। RESTful সমাধানগুলি হল সেইগুলি যেগুলি শুধুমাত্র একটি RESTful সম্পদের প্রতিনিধিত্ব করার জন্য বৈশিষ্ট্যগুলি ব্যবহার করে৷
একটি RESTful API-এ, ব্যবহারকারী একটি URL-এ একটি প্রশ্ন জমা দেয় - ইউনিফর্ম রিসোর্স লোকেটার, যা JSON, XML বা যেকোনো সমর্থিত ডেটা বিন্যাসে একটি পেলোড সহ একটি উত্তর দেয়৷ এই পেলোড ব্যবহারকারীর চাওয়া সম্পদ প্রতিনিধিত্ব করে। সাধারণ ক্লায়েন্ট অনুরোধ অন্তর্ভুক্ত
- একটি HTTP পদ্ধতি যা রিসোর্সে কী প্রক্রিয়া করা হবে তা নির্দিষ্ট করে
- সম্পদের পথ
- ক্যোয়ারী সম্পর্কে তথ্য আছে যে শিরোনাম
- একটি ক্লায়েন্ট-নির্দিষ্ট বার্তা পেলোড
হেডারের Accept ফিল্ডে, ব্যবহারকারী যে ডেটা টাইপগুলি গ্রহণ করতে সক্ষম তা নির্দিষ্ট করে। একটি কন্টেন্ট-টাইপ হেডার যা রেসপন্স বডিতে নিয়োজিত মেসেজ ডেলিভারি ফরম্যাট শনাক্ত করে সেটি এপিআই সার্ভারের মাধ্যমে পাঠানো হয় ডেটা পেলোড সহ এটি ব্যবহারকারীকে কোয়েরি করার জন্য ডেলিভার করে। একটি উত্তর কোড যা ব্যবহারকারীকে API কলের ফলাফলের স্থিতি সম্পর্কে অবহিত করে তাও প্রতিক্রিয়া বডিতে অন্তর্ভুক্ত করা হয়েছে।
g RPC কি?
g RPC - Google Remote Procedure Call - হল RPC ডিজাইনের একটি উপপ্রকার। g RPC হল একটি উচ্চ-পারফরম্যান্স গ্লোবাল, ওপেন সোর্স RPC আর্কিটেকচার যা মাইক্রোসার্ভিস আর্কিটেকচারের জন্য নমনীয়তা এবং গতির নিশ্চয়তা দেয়। বিভিন্ন কোডিং ভাষা ব্যবহার করে তৈরি মাইক্রোসার্ভিসে গ্রাহকের মিথস্ক্রিয়া নিশ্চিত করতে g RPC দ্বারা ফাংশন কলগুলি ব্যবহার করা হয়।
এই কৌশলটি HTTP 2.0 স্ট্যান্ডার্ড ব্যবহার করে RPC API অনুরোধগুলি প্রয়োগ করে, কিন্তু সার্ভার বা API প্রোগ্রামারকে HTTP সম্পর্কে সচেতন করা হয় না। ফলস্বরূপ, জটিলতা হ্রাস পেয়েছে কারণ কীভাবে RPC নীতিগুলি HTTP-তে অনুবাদ করা হয় তা নিয়ে চিন্তা করার কোনও কারণ নেই।
গুগল রিমোট প্রসিডিউর কল মাইক্রোসার্ভিস জুড়ে ডেটা স্থানান্তরের গতি বাড়াতে চায়। দূরবর্তী রিটার্ন এবং কল করার অনুমতি দেওয়ার জন্য, এটি একটি কৌশলের উপর ভিত্তি করে যা একটি পরিষেবা সনাক্ত করে, পদ্ধতিগুলি স্থাপন করে এবং প্রাসঙ্গিক ভেরিয়েবলগুলি নির্দিষ্ট করে।
উপরন্তু, এটি একটি IDL ব্যবহার করে - ইন্টারফেস বর্ণনা ভাষা - RPC API দৃষ্টান্ত নির্দিষ্ট করতে, এটি দূরবর্তী ফাংশন সনাক্ত করা সহজ করে তোলে। IDL পরিষেবা ইন্টারফেস এবং পেলোড বার্তাগুলির বিন্যাস সংজ্ঞায়িত করার জন্য ডিফল্টরূপে প্রোটোকল বাফার নিয়োগ করে।
কিভাবে g RPC কাজ করে?
HTTP/2 প্রোটোকল, স্ট্রিমিং, এবং প্রোটোকল বাফার বা protobufs বার্তা প্রেরণের জন্য g RPC API দ্বারা ব্যবহৃত হয়। প্রোটোবুফ নামক একটি সিরিয়ালাইজেশন স্ট্যান্ডার্ড ব্যবহারকারীর লাইব্রেরিগুলি স্বয়ংক্রিয়ভাবে তৈরি করতে এবং মাইক্রোসার্ভিসের সহজবোধ্য নির্মাণের অনুমতি দেয়। প্রোটো ফাইলগুলিতে, API ডিজাইনাররা সার্ভার এবং ক্লায়েন্ট জুড়ে প্রেরিত অপারেশন এবং বার্তাগুলি বর্ণনা করে।
protoc কম্পাইলার ফাইলগুলি লোড করে এবং দূরবর্তী পরিষেবাগুলির সাথে যোগাযোগের জন্য ব্যবহারকারী এবং সার্ভার সফ্টওয়্যার তৈরি করে। XML বা JSON ফর্ম্যাটের তুলনায়, প্রোটোকল বাফারগুলির সাথে এনক্রিপ্ট করা বার্তাগুলি যথেষ্ট ছোট, যা প্রক্রিয়াকরণকে কম CPU নিবিড় করে তোলে।
উপরন্তু, HTTP/2 ব্যবহার করে, g RPC API RPC ডিজাইনে বিভিন্ন উন্নতি নিয়ে আসে। প্রোটোকল একটি বাইনারি বিন্যাস স্তর যুক্ত করে যা প্যাকেটগুলিকে ছোট, বাইনারি-ফ্রেমযুক্ত বার্তাগুলিতে বিভক্ত করে, তাদের পরিবহনযোগ্য এবং ছোট রেন্ডার করে। দ্বিমুখী যোগাযোগের আর্কিটেকচারের সাথে একাধিক যুগপত প্রশ্নের জন্য HTTP/2-এর সমর্থন দ্বারা একটি একক চ্যানেলের মধ্যে অনেকগুলি কল সম্পাদন করা সম্ভব হয়েছে।
HTTP/2 ট্রান্সপোর্ট প্রোটোকল একাধিক সমবর্তী স্ট্রীম সমর্থন করে, কিন্তু g RPC API চ্যানেলগুলির মাধ্যমে এই কার্যকারিতা প্রসারিত করে। প্রতিটি চ্যানেল অনেকগুলি সমসাময়িক সংযোগের মাধ্যমে একযোগে চলমান একাধিক স্ট্রীম মিটমাট করতে পারে। চ্যানেলগুলি একটি প্রদত্ত ঠিকানা এবং পোর্টে API সার্ভারের সাথে সংযোগ করার একটি সহজ পদ্ধতি অফার করে। একটি ক্লায়েন্ট স্টাব চ্যানেলের মাধ্যমেও তৈরি করা যেতে পারে।
g RPC বনাম REST: তুলনা
বিদ্যমান API আর্কিটেকচার শৈলীর কিছু সীমাবদ্ধতা মোকাবেলা করার জন্য Google একটি RPC বৈকল্পিক হিসাবে g RPC তৈরি করেছে। এটি REST API-এর সাথে সম্পর্কিত কিছু সমস্যার সমাধান করে, কিন্তু g RPC APIগুলি একটি সাম্প্রতিক প্রযুক্তি হওয়ার কারণে কিছু সমস্যার সম্মুখীন হয়। অনেকগুলি ব্যবহারের ক্ষেত্রে রয়েছে যেখানে REST APIগুলি আপনার অ্যাপ্লিকেশনের জন্য আরও উপযুক্ত হতে পারে। আপনি উভয়ের মধ্যে পার্থক্য জানলে এই APIগুলির মধ্যে কোনটি আপনার সফ্টওয়্যারের সাথে ভাল কাজ করতে পারে তা আপনি সিদ্ধান্ত নিতে পারেন।
HTTP 1.1 বনাম HTTP 2
REST API দ্বারা ব্যবহৃত অনুরোধ-উত্তর পদ্ধতি প্রাথমিকভাবে HTTP 1.1-এর উপর ভিত্তি করে। এর মানে হল যে যদি একটি মাইক্রোসার্ভিস একাধিক ক্লায়েন্টের কাছ থেকে অনেকগুলি ক্যোয়ারী পায়, যা পুরো সিস্টেমকে টেনে নিয়ে যায় তাহলে মডেলটিকে অবশ্যই প্রতিটি প্রশ্ন পৃথকভাবে প্রক্রিয়া করতে হবে। REST API গুলি HTTP 2-এ তৈরি করা যেতে পারে, কিন্তু যোগাযোগের স্থাপত্য এখনও অনুরোধ-প্রতিক্রিয়া হিসাবে, তারা দ্বিমুখী সামঞ্জস্যতা এবং স্ট্রিমিং মিথস্ক্রিয়া সহ HTTP 2-এর সুবিধাগুলি সম্পূর্ণরূপে ব্যবহার করতে অক্ষম।
g RPC API এই চ্যালেঞ্জের সম্মুখীন হয় না। এটি একটি ক্লায়েন্ট-প্রতিক্রিয়া সংযোগ মডেল মেনে চলে এবং এটি HTTP 2 এর উপর ভিত্তি করে তৈরি। g RPC বিভিন্ন ক্লায়েন্টের কাছ থেকে অনেক প্রশ্ন গ্রহণ করতে পারে এবং স্ট্রিমিং তথ্যের মাধ্যমে একই সময়ে সেই অনুরোধগুলি প্রক্রিয়া করতে পারে। এই পরিস্থিতিতে স্ট্রিমিং ইন্টারঅ্যাকশনের সাথে দ্বিমুখী যোগাযোগের অনুমতি দেয়। অতিরিক্তভাবে, g RPC HTTP 1.1 দ্বারা সৃষ্ট অনুরূপ মিথস্ক্রিয়া সমর্থন করে।
g RPC APIগুলি পরিচালনা করতে পারে:
- ইউনারি মিথস্ক্রিয়া
যদি একটি ক্লায়েন্ট একটি একক অনুরোধ করে, কিন্তু বিনিময়ে শুধুমাত্র একটি উত্তর দেওয়া হয়। - সার্ভার স্ট্রিমিং
এটি সার্ভার স্ট্রিমিং হিসাবে পরিচিত যখনই একটি সার্ভার বার্তার একটি স্ট্রিম সহ একটি ক্লায়েন্ট প্রশ্নের উত্তর দেয়। সার্ভার সমস্ত ডেটা সরবরাহ করার পরে পদ্ধতিটি মোড়ানোর জন্য একটি স্থিতি বার্তা পাঠায়। - ক্লায়েন্ট-স্ট্রিমিং
এটি ঘটে যখন ক্লায়েন্ট বার্তাগুলির একটি ক্রম সরবরাহ করে এবং সার্ভার একটি একক বার্তা দিয়ে প্রতিক্রিয়া জানায়। - দ্বিমুখী স্ট্রিমিং
এটি উভয় উপায়ে ডেটা ট্রান্সমিশনের অনুমতি দেয় কারণ সার্ভার এবং ক্লায়েন্ট চ্যানেল একে অপরের থেকে স্বাধীন।
ব্রাউজার সমর্থন
যেহেতু বেশিরভাগ ওয়েব API ইন্টারঅ্যাকশন অনলাইনে হয়, তাই ব্রাউজার সমর্থন g RPC বনাম REST বিতর্কে একটি মূল বিবেচ্য বিষয়। ব্রাউজার সমর্থন সম্ভবত g RPC এর উপর REST API-এর অন্যতম প্রধান সুবিধা। সমস্ত ব্রাউজার সম্পূর্ণ REST API ক্ষমতা এবং ব্রাউজার সমর্থন অফার করে। ব্রাউজারে g RPC এর কার্যকারিতা, যদিও, এখনও তুলনামূলকভাবে সীমাবদ্ধ। দুর্ভাগ্যবশত, HTTP 1.1 এবং HTTP 2 জুড়ে রূপান্তরের জন্য gRPC-ওয়েবের পাশাপাশি একটি প্রক্সি স্তর প্রয়োজন। ফলস্বরূপ, g RPC APIগুলি প্রাথমিকভাবে অভ্যন্তরীণ বা ব্যক্তিগত সিস্টেমগুলির জন্য ব্যবহার করা হয়, উদাহরণস্বরূপ, নির্দিষ্ট সংস্থাগুলির ব্যাকএন্ড তথ্য এবং কার্যকারিতার জন্য নিযুক্ত API অ্যাপ্লিকেশনগুলিতে।
মাল্টিপ্লেক্সড স্ট্রীম HTTP/2 প্রোটোকলের সাথে ব্যবহার করা হয়। ফলস্বরূপ, অসংখ্য গ্রাহক প্রতিটির জন্য একটি নতুন TCP সেশন খোলার প্রয়োজন ছাড়াই সমান্তরালভাবে প্রশ্ন পাঠাতে পারেন। অতিরিক্তভাবে, সার্ভার ক্লায়েন্টদের কাছে বার্তা সরবরাহ করতে বিদ্যমান লিঙ্কটি ব্যবহার করতে পারে।
প্রতিনিধিত্বমূলক রাষ্ট্র স্থানান্তর মডেলের ব্যাপক ব্রাউজার সমর্থন রয়েছে কারণ এটি HTTP 1.1 সংহত করে। HTTP 1.1, যা REST সক্ষম করে, প্রতিটি প্রশ্নের জন্য একটি TCP হ্যান্ডশেকিং পদ্ধতি ব্যবহার করে। REST API-এর প্রায়শই লেটেন্সি সমস্যা হয় ফলস্বরূপ হ্যান্ডশেক করতে সময় লাগে।
পেলোড ডেটা স্ট্রাকচার
g RPC বনাম REST দেখার সময় যদি আমরা পেলোড ডেটা স্ট্রাকচারের দিকে তাকাই, g RPC এপিআই ডিজাইন অনুসারে প্রোটোকল বাফার ব্যবহার করে পেলোড ডেটা সিরিয়ালাইজ করে। এই পদ্ধতিটি হালকা কারণ এটি বার্তাগুলিকে ছোট করে এবং একটি অত্যন্ত সংকুচিত কাঠামোর জন্য অনুমতি দেয়। প্রোটোকল বাফারগুলি বাইনারি বিন্যাসে থাকে; তাই, তথ্য বিনিময়ের জন্য, এটি তথ্যকে সিরিয়ালাইজ করে এবং ডিসিরিয়ালাইজ করে। Protobuf স্বয়ংক্রিয়ভাবে ক্লায়েন্ট এবং সার্ভার প্রোগ্রামিং ভাষায় ভারী লিখিত বার্তা অনুবাদ করতে পারে।
REST, যাইহোক, তথ্য প্রদান এবং গ্রহণ করতে বেশিরভাগ JSON বা XML ফর্ম ব্যবহার করে। JSON হল সর্বাধিক ব্যবহৃত ফর্ম্যাট কারণ এটির অভিযোজনযোগ্যতা এবং একটি সুনির্দিষ্ট কাঠামো মেনে চলা ছাড়া গতিশীল ডেটা যোগাযোগ করার ক্ষমতা, যদিও এটির কোন প্রয়োজন নেই। JSON এর মানব-পঠনযোগ্য গুণমান, যা প্রোটোবাফ এখনও মেলে না, আরেকটি গুরুত্বপূর্ণ সুবিধা।
JSON, যাইহোক, একবার ডেটা স্থানান্তর করার সাথে সাথে দ্রুত বা হালকা হয় না। এটি REST ব্যবহার করার সময় সার্ভার এবং ক্লায়েন্ট উভয় ক্ষেত্রেই নিযুক্ত প্রোগ্রামিং ভাষাগুলিতে JSON কে সিরিয়ালাইজ করা এবং অনুবাদ করা উচিত। এটি ডেটা ট্রান্সমিশন প্রক্রিয়ার একটি অতিরিক্ত পদক্ষেপ, যা দক্ষতার ক্ষতি করতে পারে এবং ভুল হওয়ার সম্ভাবনা বাড়িয়ে তুলতে পারে।
কোড প্রজন্ম
ইঞ্জিনিয়ারদের অবশ্যই তৃতীয় পক্ষের সরঞ্জামগুলি নিয়োগ করতে হবে যেমন পোস্টম্যান API প্রশ্নের জন্য কোড জেনারেশনের জন্য, এবং g RPC এর বিপরীতে, REST API-এ বিল্ট-ইন কোড তৈরির সুবিধার অভাব রয়েছে। এর বিপরীতে, g RPC তার protoc কম্পাইলারের কারণে নেটিভ কোড জেনারেশন বৈশিষ্ট্যগুলি অফার করে, যা অনেক প্রোগ্রামিং ভাষা সমর্থন করে। কোড তৈরি করা মাইক্রোসার্ভিসের জন্য বিশেষভাবে সুবিধাজনক যা একাধিক প্ল্যাটফর্ম এবং ভাষায় তৈরি করা অসংখ্য পরিষেবাকে একত্রিত করে। সামগ্রিকভাবে, এর অন্তর্নির্মিত কোড জেনারেশন সফটওয়্যার ডেভেলপমেন্ট কিট - SDK - সহজতর করে তোলে।
REST API, অন্যদিকে, নেটিভ কোড জেনারেশন বৈশিষ্ট্য প্রদান করে না। বেশ কয়েকটি ভাষায় API কলের জন্য কোড জেনারেশন তৈরি করতে আপনাকে অবশ্যই একটি তৃতীয় পক্ষের প্রোগ্রাম ব্যবহার করতে হবে। যদিও এটা কোনো ঝামেলা নয়, এটা মনে রাখা গুরুত্বপূর্ণ যে g RPC কোড তৈরির জন্য অন্য কোনো পরিষেবার উপর নির্ভর করে না।
কখন REST API ব্যবহার করবেন
g RPC বনাম REST তুলনা করার সময়, মাইক্রোসার্ভিসেসে নির্মিত পরিকাঠামোগুলিকে একীভূত করার জন্য সবচেয়ে ব্যাপকভাবে নিযুক্ত এবং ভাল পছন্দের APIগুলি হল REST API। আপনি একটি অভ্যন্তরীণ নেটওয়ার্ক বা একটি উন্মুক্ত প্ল্যাটফর্ম তৈরি করছেন কিনা তা নির্বিশেষে, REST APIগুলি অ্যাপ সংযোগের জন্য একটি দীর্ঘ সময়ের জন্য ডিফল্ট বিকল্প হিসাবে অবিরত থাকার সম্ভাবনা রয়েছে যা বিশ্বের বাকি অংশে এর সম্পদগুলিকে খোলে। REST APIগুলি দ্রুত পুনরাবৃত্তি এবং HTTP প্রোটোকল মান প্রয়োজন এমন সিস্টেমগুলির জন্যও উপযুক্ত।
ওয়েব সার্ভিস ডেভেলপমেন্ট, মাইক্রোসার্ভিসেস এবং অ্যাপ ইন্টারফেসের জন্য REST API আপনার প্রথম পছন্দ হতে পারে কারণ তৃতীয় পক্ষের প্রযুক্তি সর্বজনীনভাবে তাদের সমর্থন করে। g RPC এর বিপরীতে, এটিতে ব্যাপক ব্রাউজার সমর্থন রয়েছে এবং এটি ব্যক্তিগত সিস্টেমে সীমাবদ্ধ নয়। এটি REST APIগুলিকে অনেক প্রসঙ্গে খুব দরকারী করে তুলতে পারে।
এটি REST সহজ, কারণ এটির ইন্টারনেটে বিস্তৃত API ডকুমেন্টেশন উপলব্ধ রয়েছে। আপনি যদি সময় সংকটে থাকেন তবে এই সহজ শেখার বক্ররেখাটি খুবই গুরুত্বপূর্ণ। আপনি গবেষণা এবং শেখার অনেক সময় বাঁচাতে পারেন এবং অবিলম্বে বাস্তবায়ন শুরু করতে পারেন। RESTful APIগুলি অ্যাপ্লিকেশনগুলিতে সংহত করাও সহজ৷ তারা আরও ভাল মাপযোগ্যতা অফার করে। আপনি শীঘ্রই আপনার অ্যাপ্লিকেশন প্রসারিত করতে চান, REST API ব্যবহার করা ভাল হতে পারে। রাষ্ট্র এবং গোপনীয়তার অভাব নির্দিষ্ট অ্যাপ্লিকেশনগুলিতে প্রতিনিধিত্বমূলক রাষ্ট্র স্থানান্তরের সাথে সমস্যা সৃষ্টি করতে পারে। যদি আপনার অ্যাপ্লিকেশনে অর্থপ্রদানের বিকল্প থাকে, তাহলে g RPC একটি ভাল বিকল্প হতে পারে।
কখন g RPC API ব্যবহার করবেন
g RPC বনাম REST উভয় ক্ষেত্রেই, অধিকাংশ তৃতীয় পক্ষের সরঞ্জাম এখনও g RPC সম্মতির জন্য অন্তর্নির্মিত কার্যকারিতা প্রদান করে না। ফলস্বরূপ, g RPC API গুলি বেশিরভাগই অভ্যন্তরীণ সিস্টেম বা কাঠামো তৈরি করতে ব্যবহৃত হয় যা বাইরের ব্যবহারকারীদের কাছে অ্যাক্সেসযোগ্য নয়। সেই যোগ্যতার কথা মাথায় রেখে, নিম্নলিখিত পরিস্থিতিতে g RPC API ব্যবহার করতে পারে:
- মাইক্রো সার্ভিস সংযোগ
g RPC APIগুলি হালকা মাইক্রোসার্ভিসেস দিয়ে তৈরি আর্কিটেকচারগুলিকে লিঙ্ক করার জন্য বিশেষভাবে সহায়ক যেখানে কম লেটেন্সি এবং দ্রুত ব্যান্ডউইথ যোগাযোগের কারণে বার্তা বিতরণের কার্যকারিতা অত্যন্ত গুরুত্বপূর্ণ৷
- বহু-ভাষা সিস্টেম
g RPC একটি বহুভুজ প্রেক্ষাপটে যোগাযোগ পরিচালনা করতে পারদর্শী হয়েছে প্রোগ্রামিং ভাষার বিস্তৃত পরিসরের জন্য এর নেটিভ কোড তৈরি করার ক্ষমতার জন্য ধন্যবাদ।
- রিয়েল-টাইম স্ট্রিমিং
যদি রিয়েল-টাইম যোগাযোগের প্রয়োজন হয়, তাহলে আপনার সিস্টেম ইউনারি ক্লায়েন্ট-রিস্পন্স ইন্টারঅ্যাকশনের জন্য অপেক্ষা না করেই রিয়েল টাইমে ডেটা প্রেরণ এবং গ্রহণ করতে পারে, জিআরপিসি দ্বিমুখী স্ট্রিমিং পরিচালনা করার ক্ষমতার জন্য ধন্যবাদ।
- কম শক্তি এবং কম ব্যান্ডউইথ নেটওয়ার্ক
এই ধরনের নেটওয়ার্কগুলি জিআরপিসি-এর সিরিয়ালাইজড প্রোটোবাফ সেশনগুলির ব্যবহার থেকে উপকৃত হতে পারে কারণ তারা হালকা যোগাযোগ, উন্নত দক্ষতা এবং দ্রুততা প্রদান করে। উদাহরণস্বরূপ, একটি নেটওয়ার্ক যা g RPC API থেকে লাভ করবে তা হল ইন্টারনেট অফ থিংস।
AppMaster কিভাবে সাহায্য করে?
সাম্প্রতিক দশকগুলিতে প্রোগ্রামিং অনেক পরিবর্তিত হয়েছে, নতুন প্রযুক্তি এবং কাঠামো ডেভেলপারদের কাজগুলিকে সহজ করে তুলেছে। No-code প্রজন্ম এটিকে পরবর্তী স্তরে নিয়ে যায়। লোকেদের খাড়া শেখার বক্ররেখার মধ্য দিয়ে যেতে হবে না এবং AppMaster মতো no-code প্ল্যাটফর্মের সাথে দ্রুত অ্যাপ্লিকেশন বিকাশ করতে পারে।
AppMaster আপনাকে আপনার অ্যাপ্লিকেশনের নির্দিষ্ট চাহিদা অনুযায়ী স্ক্র্যাচ থেকে সোর্স কোড তৈরি করতে সাহায্য করে। জেনারেট করা কোডটি আপনারই হবে এবং আপনি আপনার প্রয়োজন অনুযায়ী এটি পরিবর্তন করতে পারবেন। আপনি AppMaster এর মাধ্যমে আপনার অ্যাপ্লিকেশনের প্রয়োজনীয় বিভিন্ন মডিউল তৈরি করতে পারেন। পুরো ডেভেলপমেন্ট টিমকে একই কাজ করার চেয়ে এটি অনেক কম ব্যয়বহুল এবং সময়সাপেক্ষ।
ডেভেলপাররা অ্যাপমাস্টারের no-code জেনারেটিং প্ল্যাটফর্ম ব্যবহার করে g RPC প্রোটোকল ব্যবহার করে ব্যাকএন্ড মাইক্রোসার্ভিসেস আর্কিটেকচারের মধ্যে প্রশ্ন পাঠাতে পারে। g RPC সমর্থন বাড়ানোর জন্য আমরা পরের বছর g RPC ওয়েব পরিষেবা বিকাশের পাশাপাশি g RPC মোবাইল অ্যাপ উভয়ের সাথে API যোগ করব।
উপসংহার
অতীতে এপিআই ডেভেলপমেন্টের ক্ষেত্রে প্রতিনিধিত্বমূলক রাষ্ট্রের স্থানান্তর ছিল সর্বোত্তম পদ্ধতি। কিন্তু g RPC বনাম REST এর মধ্যে, g RPC APIগুলি ধীরে ধীরে আরও জনপ্রিয় হয়ে উঠছে। বিভিন্ন বৈশিষ্ট্য থাকা সত্ত্বেও যা এটিকে আলাদা করে তোলে, কিছু সমস্যা, যেমন ব্রাউজার সমর্থন এবং API ডকুমেন্টেশনের অভাব, এটিকে সর্বত্র নিয়োগ করা কঠিন করে তোলে। যাইহোক, প্রযুক্তিগত অগ্রগতি এবং সম্প্রদায়ের বৃদ্ধির সাথে, আমরা আশা করতে পারি যে g RPC আজকের চ্যালেঞ্জগুলি অতিক্রম করবে।
পরিশেষে, REST বা g RPC, বা GraphQL বা SOAP এর মতো অন্য যেকোনও API পদ্ধতির মধ্যে নির্বাচন করা আপনার প্রকল্পের নির্দিষ্ট চাহিদার উপর নির্ভর করে। কিছু অ্যাপ্লিকেশনের জন্য g RPC অফার করা সুবিধাগুলির প্রয়োজন হতে পারে, অন্যদের জন্য REST প্রদান করে এমন মৌলিক কার্যকারিতার প্রয়োজন হতে পারে। এই দুটি সক্ষম প্রযুক্তির মধ্যে বেছে নিতে আপনাকে আপনার অ্যাপ্লিকেশনের ফাংশনগুলি মূল্যায়ন করতে হবে এবং কেসগুলি ব্যবহার করতে হবে৷
