ডেটাসেট সাইজ, লেটেন্সি, পারমিশন ও ক্যাশিং দেখে সার্ভার-সাইড এবং ক্লায়েন্ট-সাইড ফিল্টারিং বেছে নেওয়ার চেকলিস্ট — UI লিক বা ঝামেলা ছাড়া দ্রুত এবং নিরাপদ নির্বাচন।
ইউআই-তে ফিল্টারিং একটিমাত্র সার্চ বক্সের বেশি কিছু। সাধারণত এতে কয়েকটি সম্পর্কিত অ্যাকশন থাকে যা ব্যবহারকারী যা দেখেন তা বদলে দেয়: টেক্সট সার্চ (নাম, ইমেইল, অর্ডার আইডি), ফ্যাসেট (স্ট্যাটাস, মালিক, তারিখ পরিসর, ট্যাগ), এবং সার্টিং (নতুন, সর্বোচ্চ ভ্যালু, শেষ কার্যকলাপ)।
মূল প্রশ্ন কোন কৌশল "ভাল"—এর চেয়ে বরং পূর্ণ ডেটাসেট কোথায় থাকে এবং কে এটি অ্যাক্সেস করার অনুমতি পাবে। যদি ব্রাউজারে এমন রেকর্ড পৌঁছে যা ব্যবহারকারী দেখতে পারবে না, তাহলে UI ভিজ্যুয়ালি লুকালে ও চললেও সংবেদনশীল ডেটা প্রকাশ পেতে পারে।
সার্ভার-সাইড বনাম ক্লায়েন্ট-সাইড ফিল্টারিং নিয়ে বেশিরভাগ বিতর্ক আসলে দুই ধরনের ব্যর্থতার প্রতি দ্রুত প্রতিক্রিয়া:
একটি তৃতীয় সমস্যা আছে যা অসংখ্য বাগ রিপোর্ট তৈরি করে: অসামঞ্জস্যপূর্ণ ফলাফল। যদি কিছু ফিল্টার ক্লায়েন্টে চালানো হয় এবং অন্যগুলো সার্ভারে, ব্যবহারকারীরা কাউন্ট, পেজ এবং টোটালে মিল পায় না। পেজিনেটেড লিস্টে এটা দ্রুত বিশ্বাস ভেঙে দেয়।
প্রায়োগিক একটি ডিফল্ট সহজ: ব্যবহারকারী পুরো ডেটাসেট অ্যাক্সেস করতে পারবেন না, তাহলে সার্ভারে ফিল্টার করুন। যদি তারা অ্যাক্সেস করতে পারেন এবং ডেটাসেট দ্রুত লোড করার জন্য ছোট, তখন ক্লায়েন্ট-সাইড ফিল্টারিং ঠিক আছে।
ফিল্টারিং শুধু “যেগুলো মেলে সেগুলো দেখাও”। কুয়েশ্চনটা কোথায় মেলানো হচ্ছে: ব্যবহারকারীর ব্রাউজারে (ক্লায়েন্ট) না আপনার ব্যাকএন্ডে (সার্ভার)।
ক্লায়েন্ট-সাইড ফিল্টারিং ব্রাউজারে চলে। অ্যাপ বেশ কিছু রেকর্ড ডাউনলোড করে (অften JSON), তারপর লোকালি ফিল্টার প্রয়োগ করে। ডেটা লোড হলে এটি তৎক্ষণাৎ অনুভূত হতে পারে, কিন্তু এটি তখনই কাজ করে যখন ডেটাসেট ছোট এবং নিরাপদভাবে প্রকাশযোগ্য।
সার্ভার-সাইড ফিল্টারিং আপনার ব্যাকএন্ডে চলে। ব্রাউজার ফিল্টার ইনপুট পাঠায় (যেমন status=open, owner=me, createdAfter=Jan 1), এবং সার্ভার কেবল মিল করা ফলাফল ফেরত দেয়। অনুশীলনে, এটি সাধারণত একটি API এন্ডপয়েন্ট যা ফিল্টার নেয়, ডাটাবেস কুয়েরি তৈরি করে, এবং পেজিনেটেড লিস্ট প্লাস টোটাল রিটার্ন করে।
একটি সহজ মানসিক মডেল:
হাইব্রিড সেটআপ সাধারণ। ভালো প্যাটার্ন হল বড় ফিল্টারগুলো সার্ভারে এন্ডফোর্স করা (পারমিশন, মালিকানা, তারিখ পরিসর, সার্চ), তারপর ছোট UI-নির্দিষ্ট টগলগুলো লোকালি ব্যবহার করা (আর্কাইভড আইটেমগুলো লুকানো, দ্রুত ট্যাগ চিপস, কলাম দৃশ্যমানতা) যাতে আরেকটি রিকোয়েস্ট দরকার না হয়।
সার্টিং, পেজিনেশন, এবং সার্চ সাধারণত একই সিদ্ধান্তের মধ্যে আসে। এগুলো পে-লোড সাইজ, ব্যবহারকারীর অনুভূতি, এবং আপনি কোন ডেটা প্রকাশ করছেন তা প্রভাবিত করে।
সবচেয়ে ব্যবহারিক প্রশ্ন দিয়ে শুরু করুন: আপনি যদি ক্লায়েন্টে ফিল্টার করেন তাহলে ব্রাউজারে কত ডেটা পাঠাবেন? যদি সৎ উত্তর হয় “কয়েকটি স্ক্রিনের চেয়ে বেশি”, তাহলে আপনি ডাউনলোড টাইম, মেমরি ব্যবহার, এবং ধীর ইন্টারেকশনের মূল্য দেবেন।
আপনি নিখুঁত অনুমান প্রয়োজন নেই। শুধু মাত্র পর্যায়-বিশ্লেষণ নিন: ব্যবহারকারী কত সারি দেখতে পারে, এবং একটি সারির গড় আকার কত? 500 আইটেমের একটি লিস্ট কয়েকটি ছোট ফিল্ড নিয়ে আলাদা, 50,000 আইটেম যেখানে প্রতিটি সারিতে লম্বা নোট, রিচ টেক্সট, বা নেস্টেড অবজেক্ট আছে তা একেবারে আলাদা।
ওয়াইড রেকর্ডই চুপচাপ পে-লোড কিলার। একটি টেবিল সারি গণনায় ছোট মনে হতে পারে কিন্তু ভারি হতে পারে যদি প্রতিটি সারিতে অনেক ফিল্ড, বড় স্ট্রিং, বা জয়েনড ডেটা (কন্ট্যাক্ট + কোম্পানি + শেষ কার্যকলাপ + ফুল ঠিকানা + ট্যাগ) থাকে। যদিও আপনি মাত্র তিনটি কলাম দেখান, টিমগুলি প্রায়ই “সব কিছু শিপ করি, কেস করব” এবং পে-লোড ফেটে যায়।
বৃদ্ধিও ভাবুন। আজ যা ঠিক আছে আগামী কয়েক মাসে কষ্টকর হয়ে উঠতে পারে। ডেটা দ্রুত বাড়লে ক্লায়েন্ট-সাইড ফিল্টারিংকে ছোট-মেয়াদী শর্টকাট হিসেবে বিবেচনা করুন, ডিফল্ট হিসেবে নয়।
রুলস অব থাম্ব:
শেষ পয়েন্টটি পারফরম্যান্সের চেয়েও গুরুত্বপূর্ণ। “পুরো ডেটাসেট ব্রাউজারে শিপ করা যায় কি?” এমন প্রশ্নই নিরাপত্তার প্রশ্ন। যদি উত্তর আত্মবিশ্বাসী না হয়, পাঠাবেন না।
ফিল্টারিংয়ের পছন্দগুলি প্রায়শই কার্যকরতার চেয়ে অনুভূতিতে ব্যর্থ হয়। ব্যবহারকারী মিলিসেকেন্ড মাপেন না—তারা বিরতি, ফ্লিকার, এবং ফলাফলগুলি দেখতে পায় যা টাইপ করার সময় উল্টে যায়।
সময় বিভিন্ন জায়গায় হারিয়ে যেতে পারে:
এই স্ক্রিনটির জন্য "দ্রুত পর্যাপ্ত" কি তা নির্ধারণ করুন। একটি লিস্ট ভিউতে টাইপিংতে প্রতিক্রিয়াশীলতা এবং মসৃণ স্ক্রলিং দরকার হতে পারে, যেখানে একটি রিপোর্ট পেজ হালকা অপেক্ষা সহ্য করতে পারে যতক্ষণ প্রথম রেজাল্ট দ্রুত দেখায়।
শুধু অফিস Wi‑Fi-র ওপর বিচার করবেন না। ধীর কানেকশনে ক্লায়েন্ট-সাইড ফিল্টারিং প্রথম লোডের পরে দারুণ মনে হতে পারে, কিন্তু সেই প্রথম লোড ধীর হতে পারে। সার্ভার-সাইড ফিল্টারিং পে-লোড ছোট রাখে, কিন্তু প্রতিটি কীস্ট্রোক-এ রিকোয়েস্ট করলে তা ধীর মনে হতে পারে।
মানব ইনপুট অনুযায়ী ডিজাইন করুন। টাইপ করার সময় রিকোয়েস্ট ডিবাউন্স করুন। বড় রেজাল্ট সেটের জন্য প্রগ্রেসিভ লোডিং ব্যবহার করুন যাতে পেজ দ্রুত কিছু দেখায় এবং ব্যবহারকারী স্ক্রল করার সাথে সাথে মসৃণ থাকে।
পারমিশন আপনার ফিল্টারিং পন্থা ঠিক করার চেয়ে অধিক প্রাধান্য পাওয়া উচিত। ব্রাউজারে যদি কখনও এমন ডেটা চলে যায় যা ব্যবহারকারী দেখতে পারবে না, তখন আপনি ইতিমধ্যেই সমস্যায় রয়েছেন, এমনকি আপনি UI-এ এটা লুকালেও।
এই স্ক্রিনে কোন অংশগুলো সংবেদনশীল তা নামকরণ করে শুরু করুন। কিছু ফিল্ড স্পষ্ট (ইমেইল, ফোন নম্বর, ঠিকানা)। অন্যগুলো সহজে চোখে না পড়ে: ইন্টারনাল নোট, কস্ট বা মার্জিন, বিশেষ প্রাইসিং রুল, রিস্ক স্কোর, মডারেশান ফ্ল্যাগ।
বড় ফাঁদ হল “আমরা ক্লায়েন্টে ফিল্টার করি, কিন্তু কেবল অনুমোদিত সারি দেখাই।” তা একথা বোঝায় যে পুরো ডেটাসেট ডাউনলোড করা হয়েছে। যে কেউ নেটওয়ার্ক রেসপন্স পরীক্ষা করতে পারে, ডেভটুলসে খুলে দেখতে পারে, বা পে-লোড সেভ করতে পারে। UI-এ কলাম লুকানো অ্যাক্সেস কন্ট্রোল নয়।
যখন অথরাইজেশন ব্যবহারকারী অনুসারে পরিবর্তিত হয়, বিশেষভাবে যখন বিভিন্ন ব্যবহারকারী ভিন্ন সারি বা ভিন্ন ফিল্ড দেখতে পারে, তখন সার্ভার-সাইড ফিল্টারিং নিরাপদ ডিফল্ট।
দ্রুত চেক:
যদি কোন উত্তর হ্যাঁ হয়, সার্ভারে ফিল্টার এবং ফিল্ড সিলেকশন রাখুন। কেবল সেই ডেটা পাঠান যা ব্যবহারকারী দেখতে অনুমতি পায়, এবং সার্চ, সর্ট, পেজিং, এবং এক্সপোর্টে একই নিয়ম প্রয়োগ করুন।
উদাহরণ: একটি CRM কন্ট্যাক্ট লিস্টে, রিপরা তাদের নিজস্ব অ্যাকাউন্ট দেখতে পারে, ম্যানেজাররা তাদের টিমের সব দেখেন। যদি ব্রাউজার সব কন্ট্যাক্ট ডাউনলোড করে এবং লোকালি ফিল্টার করে, একটি রিপ এখনো লুকানো অ্যাকাউন্ট রেসপন্স থেকে পুনরুদ্ধার করতে পারবে। সার্ভার-সাইড ফিল্টারিং তা প্রতিরোধ করে কারণ সার্ভার সেই রো গুলোই পাঠায় না।
ক্যাশিং একটি স্ক্রিনকে মুহূর্তের মধ্যে অনুভব করাতে পারে। এটা ভুল সত্য দেখাতেও পারে। মূল বিষয় হল আপনি কী পুনরায় ব্যবহার করতে পারবেন, কতক্ষণ, এবং কোন ইভেন্টগুলো ক্যাশ মুছে ফেলবে।
ক্যাশ ইউনিট প্রথমে বেছে নিন। পুরো লিস্ট ক্যাশ করা সহজ কিন্তু সাধারণত ব্যান্ডউইডথ অপচয় করে এবং দ্রুত স্টেল হয়ে যায়। পেজ ক্যাশ করা ইনফিনিট স্ক্রলের জন্য ভাল। কুয়েরি রেজাল্ট (ফিল্টার + সর্ট + সার্চ) ক্যাশ করা সঠিক, কিন্তু ইউজার অনেক কম্বিনেশন ট্রাই করলে দ্রুত বাড়ে।
কিছু ডোমেনে ফ্রেশনেস আরও গুরুত্বপূর্ণ। ডেটা দ্রুত বদলে গেলে (স্টক লেভেল, ব্যালান্স, ডেলিভারি স্টেটাস), এমনকি ৩০ সেকেন্ড ক্যাশও ব্যবহারকারীকে বিভ্রান্ত করতে পারে। ডেটা ধীরে বদলে গেলে (আর্কাইভড রেকর্ড, রেফারেন্স ডেটা), দীর্ঘ ক্যাশ ঠিক আছে।
কোড করার আগে ইনভ্যালিডেশন প্ল্যান করুন। সময় পেরোনোর ছাড়া, কোন ঘটনাগুলো রিফ্রেশ বাধ্যতামূলক করবে তা নির্ধারণ করুন: ক্রিয়েট/এডিট/ডিলিট, পারমিশন পরিবর্তন, বাল্ক ইম্পোর্ট বা মার্জ, স্টাটাস ট্রানজিশন, আনডু/রোলব্যাক, এবং ব্যাকগ্রাউন্ড জব যা ফিল্টার করা ফিল্ড আপডেট করে।
ক্যাশ কোথায় থাকবে তাও ঠিক করুন। ব্রাউজার মেমরি ব্যাক/ফরওয়ার্ড নেভিগেশন দ্রুত করে, কিন্তু যদি আপনি এটি user ও org অনুযায়ী কী না করেন তবে এটি একাউন্টগুলোর মধ্যে ডেটা লিক করতে পারে। ব্যাকএন্ড ক্যাশিং পারমিশন ও কনসিস্টেন্সির জন্য নিরাপদ, কিন্তু কেশ কীতে পূর্ণ ফিল্টার সিগনেচার এবং কলারের পরিচয় থাকতে হবে যাতে রেজাল্ট মিশে না যায়।
লক্ষ্য অচলযোগ্য হিসেবে নিন: স্ক্রিন দ্রুত মনে হবে এবং ডেটা লিক করবে না।
বেশিরভাগ টিম একই প্যাটার্নে পা ফেলে: একটি UI যা ডেমোতে দুর্দান্ত দেখায়, তারপর বাস্তব ডেটা, বাস্তব পারমিশন, এবং বাস্তব নেটওয়ার্ক স্পিডে ফাটল দেখা দেয়।
সবচেয়ে গুরুতর ব্যর্থতা হল ফিল্টারিংকে উপস্থাপন হিসেবে Trata করা। যদি ব্রাউজারে যেকোনো রেকর্ড আসে যা ব্যবহারকারী দেখতে পারবে না, আপনি হেরে গেছেন।
দুই সাধারণ কারণ:
উদাহরণ: ইন্টার্নরা কেবল তাদের রিজিওনের লিড দেখবে। যদি API সব রিজিওন রিটার্ন করে এবং ড্রপডাউন React-এ লোকালি ফিল্টার করে, ইন্টার্ন পুরো লিস্ট আবারও এক্সট্র্যাক্ট করতে পারবে।
দেরি প্রায়ই অনুমান থেকে আসে:
একটি সূক্ষ্ম কিন্তু ব্যথাদায়ক সমস্যা হল নিয়মের অমিল। যদি সার্ভার এবং UI একইভাবে starts with না ট্রীট করে, ব্যবহারকারী কাউন্ট মেলায় না দেখবে বা আইটেম রিফ্রেশ করলে অদৃশ্য হয়ে যাবে।
দুটি মাইন্ডসেট নিয়ে একটি চূড়ান্ত পাস করুন: একটি কৌতূহলপূর্ণ ব্যবহারকারী এবং একটি খারাপ নেটওয়ার্ক দিন।
একটি সহজ টেস্ট: একটি সীমাবদ্ধ রেকর্ড তৈরি করুন এবং নিশ্চিত করুন এটি কখনই পে-লোড, কাউন্ট, বা ক্যাশে না প্রদর্শিত হয়, এমনকি যখন আপনি ব্যাপকভাবে ফিল্টার করেন বা ফিল্টার ক্লিয়ার করেন।
একটি CRM কল্পনা করুন যেখানে 200,000 কন্ট্যাক্ট আছে। সেলস রিপরা কেবল তাদের নিজ অ্যাকাউন্ট দেখতে পারে, ম্যানেজাররা তাদের টিম দেখতে পারে, এবং অ্যাডমিনরা সব দেখতে পারে। স্ক্রিনে সার্চ, ফিল্টার (স্ট্যাটাস, মালিক, শেষ কার্যকলাপ), এবং সর্টিং আছে।
ক্লায়েন্ট-সাইড ফিল্টারিং এখানে দ্রুত ব্যর্থ হয়। পে-লোড ভারী, প্রথম লোড ধীর, এবং ডেটা লিকের ঝুঁকি উচ্চ। UI সারি লুকালেও ব্রাউজার ডেটা পেয়েই গেছে। আপনি ডিভাইসেও চাপ ফেলেন: বড় অ্যারে, ভারি সর্টিং, বারবার ফিল্টার রান, বেশি মেমরি ব্যবহার, এবং পুরনো ফোনে ক্র্যাশ হওয়ার সম্ভাবনা।
একটি নিরাপদ পন্থা হল পেজিনেশনসহ সার্ভার-সাইড ফিল্টারিং। ক্লায়েন্ট ফিল্টার অপশন ও সার্চ টেক্সট সার্ভারে পাঠায়, এবং সার্ভার কেবল ব্যবহারকারী অনুমোদিত রো রিটার্ন করে, ফিল্টার ও সর্ট করা অবস্থায়।
একটি প্রায়োগিক প্যাটার্ন:
একটি ছোট excepción যাতে ক্লায়েন্ট-সাইড ঠিক আছে: ছোট স্থির ডেটা। “Contact status”-এর মতো ৮টি মানের ড্রপডাউন একবার লোড করা যায় এবং লোকালি ফিল্টার করা ঝুঁকি বা খরচ খুব কম।
টিমগুলি সাধারণত একবার “ভুল” অপশন বেছে নেওয়ার ফলে পোড়ে না। তারা পোড়ে যখন প্রতি স্ক্রিনে আলাদা সিদ্ধান্ত নেয়, তারপর চাপের মধ্যে লিক ও ধীর পেজগুলো ঠিক করার চেষ্টা করে।
প্রতিটি স্ক্রিনের জন্য একটি ছোট সিদ্ধান্ত নোট লিখে রাখুন: ফিল্টারগুলো—ডেটাসেট সাইজ, পাঠানোর খরচ, “দ্রুত পর্যাপ্ত” কিরকম লাগে, কোন ফিল্ড সংবেদনশীল, এবং রেজাল্ট কিভাবে ক্যাশ করা হবে (বা না হবে)। সার্ভার ও UI-কে সঙ্গত রাখুন যাতে ফিল্টারিংয়ের “দুই সত্য” না দাঁড়ায়।
যদি আপনি দ্রুত স্ক্রিনগুলো Koder.ai (koder.ai) -এ তৈরি করছেন, তাহলে আগেই সিদ্ধান্ত নিন কোন ফিল্টার ব্যাকএন্ডে বাধ্যতামূলক (পারমিশন ও রো-লেভেল অ্যাক্সেস) এবং কোন ছোট UI-টগলগুলো React লেয়ারে রাখা যাবে। সেই এক সিদ্ধান্ত প্রায়ই পরে সবচেয়ে ব্যয়বহুল রিরাইটগুলো টাল দেয়।
ডিফল্ট হিসেবে সার্ভার-সাইড ব্যবহার করুন যখন ব্যবহারকারীদের পারমিশন আলাদা থাকে, ডেটাসেট বড় হয়, বা আপনি কনসিস্টেন্ট পেজিনেশন ও টোটাল চান। ক্লায়েন্ট-সাইড শুধুমাত্র তখনই ব্যবহার করুন যখন পুরো ডেটাসেট ছোট, নিরাপদ এবং দ্রুত ডাউনলোড যোগ্য।
কারণ ব্রাউজার যেকোনো কিছুই পরীক্ষা করা যায়। UI থেকে সারি লুকালেও, ব্যবহারকারী নেটওয়ার্ক রেসপন্স, ক্যাশড পে-লোড বা ইন-মেমরি অবজেক্টে ডেটা দেখতে পাবে।
এটি সাধারণত ঘটে যখন আপনি বেশি ডেটা পাঠান এবং তারপর প্রতিটি কীস্ট্রোক-এ বড় অ্যারে ফিল্টার/সোর্ট করেন, অথবা যখন আপনি প্রতিটি কীস্ট্রোক-এ সার্ভার রিকোয়েস্ট পাঠান ডিবাউন্স না করে। পে-লোড ছোট রাখুন এবং প্রতিটি ইনপুট চেঞ্জে ভারি কাজ এড়ান।
‘রিয়েল’ ফিল্টারগুলোর জন্য এক উৎস রাখুন: পারমিশন, সার্চ, সর্টিং, এবং পেজিনেশন একসঙ্গে সার্ভারে প্রয়োগ করুন। তারপর ক্লায়েন্ট-সাইড লজিককে ছোট UI-টোগলগুলিতে সীমাবদ্ধ রাখুন যা মূল ডেটাসেট পরিবর্তন করে না।
ক্লায়েন্ট-সাইড ক্যাশিং স্টেল বা ভুল ডেটা দেখাতে পারে, এবং যদি ইউজার আইডেন্টিটি দিয়ে কী না করা হয় তবে একাউন্টগুলোর মধ্যে লিক হতে পারে। সার্ভার-সাইড ক্যাশিং পারমিশনের জন্য নিরাপদ, তবে এর কেশ কীতে পূর্ণ ফিল্টার সিগনেচার এবং কলারের পরিচয় থাকতে হবে।
দুটি প্রশ্ন জিজ্ঞাসা করুন: ব্যবহারকারী বাস্তবে কত সারি পেতে পারে, এবং প্রতিটি সারির সাইজ কত বাইট। যদি আপনি একটি সাধারণ মোবাইল কানেকশনে আরাম দিয়ে লোড করবেন না, অথবা বয়স্ক ডিভাইসে সমস্যা হবে বলে মনে করেন, তাহলে সার্ভারে ফিল্টার করুন এবং পেজিনেট করুন।
সার্ভার-সাইড। যদি রোল, টিম, রিজিওন, বা মালিকানা নিয়ম অনুযায়ী কেউ আলাদা সারি বা ফিল্ড দেখতে পায়, সার্ভারকে সারি ও ফিল্ড এক্সেস এনফোর্স করতে হবে। ক্লায়েন্ট শুধুমাত্র সে রেকর্ড এবং ফিল্ড পাবে যা ব্যবহারকারী দেখতে অধিকারী।
প্রথমেই API কনট্র্যাক্ট নির্ধারণ করুন: কোন ফিল্টারগুলো গ্রহণ করবে, ডিফল্ট সর্টিং কি, পেজিনেশন কেমন হবে, এবং সার্চ কিভাবে মিলবে (কেস, অ্যাকসেন্ট, পার্শিয়াল ম্যাচ)। তারপর ব্যাকএন্ডে একই লজিক বাস্তবায়ন করুন এবং টোটাল ও পেজগুলি মিলে কিনা টেস্ট করুন।
টাইপিং ডিবাউন্স করুন যাতে প্রতিটি কীস্ট্রোক-এ অনুরোধ না যায়, এবং নতুন রেজাল্ট আসা পর্যন্ত পুরানো রেজাল্ট দেখিয়ে রাখুন যাতে ফ্লিকার কমে। পেজিনেশন বা প্রগ্রেসিভ লোডিং ব্যবহার করুন যাতে ব্যবহারকারী দ্রুত কিছু দেখতে পান এবং পুরো বৃহৎ রেসপন্সের জন্য ব্লক না হন।
প্রথমে পারমিশন প্রয়োগ করুন, তারপর ফিল্টার ও সর্ট করুন, এবং মাত্র একটি পেজ প্লাস টোটাল কাউন্ট রিটার্ন করুন। “জাস্ট ইন কেস” অতিরিক্ত ফিল্ড পাঠানো এড়ান, এবং কেশ কিইতে user/org/role অন্তর্ভুক্ত করুন যাতে একটি রেপ কখনও ম্যানেজারের ডেটা না পায়।
