Firebase Admin Node httpAgent: পরিষেবা অনুসারে প্রক্সি কভারেজ
সমস্ত SDK ট্রাফিক একই প্রক্সি ব্যবহার করে ধরে নেওয়ার আগে নির্ধারণ করুন কোন Firebase Admin Node অপারেশনগুলো কনফিগার করা HTTP এজেন্ট ব্যবহার করে।
একটি প্রমাণীকরণ কল প্রক্সির মাধ্যমে কাজ করে, কিন্তু একটি ডেটাবেস সংযোগ ব্যর্থ হয়। Firebase অ্যাপ্লিকেশনে এটি মাঝেমধ্যে ঘটা প্রক্সির বদলে পরিবহনের পার্থক্য হতে পারে।
Admin Node SDK-এর httpAgent অ্যাপ্লিকেশন অপশনটি REST কল করা পরিষেবাগুলোতে প্রযোজ্য, যার মধ্যে Auth এবং Messaging রয়েছে। এর নথিভুক্ত পরিসর Realtime Database এবং Firestore বাদ দেয়। Credential অবজেক্টগুলোরও সংশ্লিষ্ট credential factory পদ্ধতির মাধ্যমে নিজস্ব এজেন্ট কনফিগারেশন থাকে।
| ব্যর্থ অপারেশন | যে কনফিগারেশন পরীক্ষা করবেন |
|---|---|
| একটি Admin REST পরিষেবা কল | অ্যাপ্লিকেশনের HTTP এজেন্ট |
| credential টোকেন অর্জন | credential অবজেক্টের HTTP কনফিগারেশন |
| ডেটাবেস সংযোগ | ডেটাবেস ক্লায়েন্টের নিজস্ব পরিবহন সমর্থন |
এই কারণেই initialization-এ এজেন্ট যোগ করলে পরবর্তী প্রতিটি সংযোগ একই পথ নেবে বলে নিশ্চয়তা দেওয়া যায় না। অন্য পরিষেবার জন্য ইতিমধ্যে কাজ করা কনফিগারেশন বদলানোর আগে ব্যর্থ পরিষেবা ও গন্তব্য লিপিবদ্ধ করুন।
পুরনো আলোচনায় Firebase কমান্ড-লাইন টুলকেও অ্যাপ্লিকেশন SDK-এর সঙ্গে মেশানো হয়। http_proxy পড়ার জন্য CLI সমাধান প্রমাণ করে না যে আপনার Node প্রক্রিয়ার ভিতরের ডেটাবেস ক্লায়েন্ট সেই একই অপশন ব্যবহার করে।
আপনার সত্যিই প্রয়োজনীয় পরিবহনের জন্য সমর্থিত কনফিগারেশন ইন্টারফেস ব্যবহার করুন। WebSocket-এর ভেতরের নির্ভরতা প্যাচ করলে একটি সংযোগে প্রভাব পড়লেও অন্য পথ অপরিবর্তিত থাকতে পারে, আর ভবিষ্যতে নির্ভরতা হালনাগাদ বোঝা কঠিন হয়ে যায়।