Lovable এবং Supabase-এ ১৬টি প্রোডাক্ট চালানোর ক্ষেত্রে প্রযুক্তিগত ভুলসমূহ
আমরা Inithouse-এ ১৬টি প্রোডাক্ট পরিচালনা করি। আমরা এগুলোর সবকিছুর জন্য Lovable এবং Supabase ব্যবহার করি। একটি টিমই সবকিছু ম্যানেজ করে। শুনতে এটি ভালো মনে হলেও, যখন আপনি ১৬টি কাস্টম ডোমেইন, ১৬টি Supabase প্রজেক্ট এবং ১৬টি edge functions-এর মুখোমুখি হবেন, তখন পরিস্থিতি বদলে যায়।
আমরা এমন কিছু ভুল করেছি যার কারণে আমাদের মূল্যবান সময় নষ্ট হয়েছে। নিচে পাঁচটি বড় প্রযুক্তিগত ভুল এবং আমাদের সমাধানগুলো দেওয়া হলো।
১. অসামঞ্জস্যপূর্ণ ডাটাবেস স্কিমা (Inconsistent database schemas)
আমাদের প্রথম তিনটি প্রোডাক্ট একই ধরণের ডেটার জন্য ভিন্ন ভিন্ন টেবিল নাম ব্যবহার করত। একটি প্রজেক্ট অ্যানালিটিক্সের জন্য page_views ব্যবহার করত, অন্যটি ব্যবহার করত analytics_events। এর ফলে শেয়ারড কোড (shared code) লেখা অসম্ভব হয়ে পড়েছিল। যে কাজটি একটি বিকেলেই শেষ হওয়ার কথা ছিল, তা শেষ করতে দুই সপ্তাহ লেগে গিয়েছিল।
সমাধান: আমরা একটি শেয়ারড মাইগ্রেশন টেমপ্লেট (shared migration template) তৈরি করেছি। প্রতিটি নতুন প্রোডাক্ট অ্যানালিটিক্স, ব্লগ পোস্ট এবং auth-এর জন্য একই বেস টেবিল পায়। কাজের চাপ কম থাকা সময়ে আমরা পুরনো প্রজেক্টগুলোতেও এই পরিবর্তনগুলো নিয়ে এসেছি। এখন, একটি মনিটরিং এন্ডপয়েন্ট (monitoring endpoint) যোগ করতে এক দিন নয়, বরং মাত্র ২০ মিনিট সময় লাগে।
২. ত্রুটিপূর্ণ কাস্টম ডোমেইন (Broken custom domains)
Lovable আপনাকে কাস্টম ডোমেইন কানেক্ট করার সুবিধা দেয়। মাঝে মাঝে ডিপ্লয়মেন্ট সফল হলেও DNS ভেরিফিকেশন ব্যর্থ হয়। প্রিভিউ URL কাজ করলেও লাইভ ডোমেইনটি একটি ব্ল্যাঙ্ক পেজ দেখায়। লাইভ URL চেক না করার কারণে আমরা তিন দিনের ট্রাফিক হারিয়েছিলাম।
সমাধান: আমরা একটি পোস্ট-পাবলিশ চেকলিস্ট ব্যবহার করি। প্রতিটি লাইভ ডোমেইন ভেরিফাই করার জন্য আমরা সেটি একটি ইনকগনিটো (incognito) উইন্ডোতে ওপেন করি। এছাড়াও আমরা একটি আপটাইম চেক (uptime check) যুক্ত করেছি যা ডোমেইন ফেইল করলে Slack-এ নোটিফিকেশন পাঠায়।
৩. বিচ্ছিন্ন ডেটা ভিজিবিলিটি (Fragmented data visibility)
প্রতিটি প্রোডাক্টের জন্য আলাদা আলাদা ড্যাশবোর্ড না খুলে আমাদের পুরো পোর্টফোলিও কেমন পারফর্ম করছে তা দেখা সম্ভব ছিল না। আমরা অনেকটা অন্ধকারে কাজ করছিলাম।
সমাধান: আমরা প্রতিটি Supabase প্রজেক্টে একটি stats API এন্ডপয়েন্ট ডিপ্লয় করেছি। প্রতিটি প্রোডাক্ট ইউজার এবং সাইনআপের মতো মূল মেট্রিক্সগুলো একটি স্ট্যান্ডার্ড ফরম্যাটে পাঠায়। একটি সিঙ্গেল স্ক্রিপ্ট এই ডেটাগুলো নিয়ে একটি ড্যাশবোর্ডে নিয়ে আসে।
৪. কম্পোনেন্ট কপি-পেস্ট করা (Copy-pasting components)
আমরা এক প্রজেক্ট থেকে অন্য প্রজেক্টে React কম্পোনেন্ট কপি করে আনতাম। এই কম্পোনেন্টগুলোর সাথে পুরনো কিছু ধারণা বা লজিকও চলে আসত। একটি প্রোডাক্টের প্রাইসিং কার্ড অন্য একটি প্রোডাক্টে কাজ করছিল না কারণ সেটি ভিন্ন একটি পেমেন্ট ফ্লো আশা করছিল। এই ধরণের রহস্যময় বাগ (phantom bugs) ডিবাগ করতে আমাদের অনেক দিন সময় ব্যয় করতে হতো।
সমাধান: আমরা কপি-পেস্ট করা বন্ধ করে দিয়েছি। আমরা এখন কম্পোনেন্ট প্যাটার্নের একটি ডকুমেন্ট মেইনটেইন করি। আমরা Lovable-কে এই প্যাটার্নগুলোর ওপর ভিত্তি করে একটি নতুন কম্পোনেন্ট তৈরি করতে বলি। এটি সেটআপ করতে কিছুটা বেশি সময় নিলেও মেইনটেইন করা অনেক সহজ।
৫. চ্যাট হিস্ট্রিকে ডকুমেন্টেশন হিসেবে ব্যবহার করা (Using chat history as documentation)
আমরা টেকনিক্যাল সিদ্ধান্তগুলো মনে রাখার জন্য Lovable-এর চ্যাট হিস্ট্রির ওপর নির্ভর করতাম। চ্যাট লগগুলো বেশ অগোছালো হয়। সেখানে সফল পরিবর্তন এবং ব্যর্থ প্রচেষ্টার মিশ্রণ থাকে। একটি লম্বা চ্যাট থ্রেড থেকে কোনো পরিবর্তনের নির্দিষ্ট কারণ খুঁজে বের করা কঠিন।
সমাধান: আমরা ডিসিশন লগিংয়ের (decision logging) জন্য Linear ব্যবহার শুরু করেছি। আমরা Linear-এ এক লাইনে লিখে রাখি কী পরিবর্তন করা হয়েছে এবং কেন। Lovable চ্যাট হলো কাজ করার (execution) জন্য, আর Linear হলো সিদ্ধান্তের (decisions) জন্য।
শিক্ষাটি সহজ। ১৬টি প্রোডাক্টকে ১৬টি আলাদা প্রজেক্ট হিসেবে দেখবেন না। সেগুলোকে একটি পোর্টফোলিও হিসেবে বিবেচনা করুন। আপনার টেমপ্লেটগুলোকে স্ট্যান্ডার্ডাইজ করুন এবং সবকিছু এক জায়গা থেকে মনিটর করুন।
Source: https://dev.to/jakub_inithouse/technical-mistakes-of-running-16-products-on-lovable-supabase-59fh
ঐচ্ছিক লার্নিং কমিউনিটি: https://t.me/GyaanSetuAi