ধরেন নতুন একটা বুক লিস্ট এ্যাপের প্রজেক্ট হাতে পেয়েছেন। ব্যাকেন্ড করাই আছে।
আপনি যখন কোমর বেঁধে কাজে নেমে গেলেন তখনই খেয়ে গেলেন একটা মাথায় বাড়ি। ব্যাকেন্ড ডেভেলপারের পাঠানো Open API ডকুমেন্টটা Postman এ ওপেন করেই আপনার মেজাজ গেলো খারাপ হয়ে।
Author এর লিস্ট এবং ডিটেইল এন্ডপয়েন্টের রেসপন্স যথাক্রমে
এমনঃ
এবং এমনঃ
এখন আপনার খালি চোখে কি কিছু চোখে পড়ে যাতে এমন মেজাজ খারাপ হওয়ার মতো কিছু আছে?
আচ্ছা। ধরতে না পারলে ধরিয়ে দেইঃ রেসপন্সের শেপ এ সমস্যা। অর্থাৎ author-list এর ক্ষেত্রে এর অথরের বুক গুলোর শুধুমাত্র নামের (স্ট্রিং) লিস্ট হিসেবে আসতেছে। কিন্তু author-details এ দেখলেই বুঝা যাচ্ছে যে book আরেকটা এন্টিটি(!) যার সাথে অথরের রিলেশন আছে কারণ এক্ষেত্রে শুধুমাত্র স্ট্রিং লিস্ট হিসেবে না এসে অবজেক্টের লিস্ট আসতেছে id সহ।
এক্ষেত্রে সমস্যা গুলা কি?
১) একই এন্টিটির জন্য এ্যাপ্লিকেশনে একটাই ক্লাস থাকবে। যদি ওই এন্টিটির ভ্যারিয়ান্ট থাকে তবে অবশ্যই তাদেরকে ওই ক্লাসের সাব টাইপ হতে হবে! এখানে List<String> is not a sub type of List<Book> or vice versa.
২) কোড ডুপ্লিকেশন! দুইটা এপিয়াই কলের জন্য দুইধরনের রেসপন্স অবজেক্ট বানানো এবং মেইন্টেইন করা ঝামেলার কাজ।
এছাড়াও আরও অনেক সমস্যা আছে যেগুলো মূলত এই দুইয়েরই এক্সটেন্ডেড ভার্সন। শুধু মনে রাখেন যে প্যারা খাবেন প্রচুর।
তাহলে এই কাজ ব্যাকেন্ড ডেভেলপার কেনো করছে?
আমি তো তার কথা বলতে পারিনা, আমি আমারটা বলতে পারি। আমার মনে হয় উনি ফুলস্ট্যাক ডেভেলপার যাকে প্রচুর পরিমাণ MVC স্টাইলের এ্যাপে কাজ করতে হয়। সম্ভবত উনি ভেবেছেন যে ওনার ওয়েব এ্যাপের অথর লিস্ট পেজে তো শুধু অথরের বুক গুলোর নামই দেখাতে হচ্ছে তাই অন্য ইনফরমেশন গুলোর দরকার নেই। লজিক্যাল। কিন্তু এটা করতে গিয়ে উনি উপড়ের ওই অপকর্মটা করে ফেলেছেন যার কারণে যার static typed ল্যাংগুয়েজ গুলোতে ফ্রন্টেন্ড কিংবা মোবাইল এ্যাপ্লিকেশন ডেভেলপ করেন তাদের খুব প্যারা খেতে হয়।
কিন্তু এমন তো হওয়ার কথা ছিলোনা ডেভেলপার-ডেভেলপার তো জাতভাই। তাহলে এক ডেভেলপার আরেক ডেভেলপারকে প্যারা দিবে কেনো?
তাইতো! তাহলে ব্যাকেন্ড ডেভেলপার কি করতে পারতো?
খুবই সাধারণ বিষয় খেয়াল রাখলেই হয়। উনি যেহেতু ব্যাকেনড ডেভেলপার নিশ্চই তার পুরো এপ্লিকেশনের এন্টিটি (টেবিল) কয়টা এবং কি কি তা জানার কথা। আচ্ছা খেয়াল করেছেন, প্রত্যেকটা এন্টিটির একটা কমন বিষয় (ফিল্ড) আছে, id. অর্থাৎ প্রত্যেকটা আলাদা এন্টিটির রেসপন্সের জন্য এই ফিল্ড টা থাকা বাধ্যতামূলক। কারণ এইটাই এন্টিটির জন্য ইউনিক। যেমন দুইজন অথরের নাম এক হতেই পারে, কিন্তু তারা যে আলাদা ব্যক্তি তা তাদের id ই বলে দিবে। বইয়ের ক্ষেত্রেও একই। দুইজন লেখক একই নামে দুইটা বই লিখতেই পারে, কিন্তু বই দুইটা যে একই বই না তা বুঝার উপায় হচ্ছে তাদের আইডির ভিন্নতা।
তাহলে author-list এবং author-detail এর রেসপন্সে কি পরিবর্তন আসতো?
author-details ঠিকঠাক আছে। বুক লিস্ট গুলা যদিওবা অন্য আরেকটা এন্ডপয়েন্টে সেগ্রেগেট করা যেতো, কিন্তু সেটা ভিন্ন বিষয়। এটা করারও সুবিধা অসুবিধা আছে। অন্য আরেকদিন এ বিষয়ে হয়তো কথা বলা যাবে।
author-list এ ইতোমধ্যে বুঝতেই পারছেন সমস্যাটা কি? রেসপন্সটা হওয়া উচিৎ ছিলো এরকমঃ
এখন ফ্রন্টেন্ড ডেভেলপার কি করবে?
সে book এন্টিটির জন্য একটাই টাইপ (ক্লাস) ডিফাইন করবে। যাতে শুধুমাত্র id এবং title রিকুয়ার্ড ফিল্ড হিসেবে থাকবে, বাঁকি সব ফিল্ড অপশনাল বা নাল্যাবল থাকবে।
কিছুটা এমন (ফ্লাটারের ক্ষেত্রে):
এতে করে কি উপকারটা হলো?
১) প্রথমত পুরো এ্যাপ জুড়ে book এর জন্য একটা এন্টিটি ডিফাইন করা থাকলো। চিন্তাভাবনায়ও ওভারহেড কমলো, অর্থাৎ এপ্লিকেশন ডোমেইন সিমপ্লিফাইড হলো।
২) কোড ডুপ্লিকেশন অনেকহারে কমলো। বাড়তি কাজ করা লাগলোনা।
৩) সবচাইতে বড়ো কথা জাতভাইয়ের উপর মেজাজ খারাপ হলোনা।
আচ্ছা দাঁড়ান! অথরের ক্লাসটাও দেই, দেখেন তো কোনো সমস্যা দেখতে পান কিনা।
পাননি? না পেলে পরের কোনো পর্বে এ নিয়ে আলোচনা করা যাবে।
