AI দিয়ে বানানো একটা app-এর ভেতরে আসলে কী আছে: নন-ডেভেলপারদের জন্য একটা ট্যুর

আপনি একটা বর্ণনা টাইপ করলেন, go চাপলেন, আর বিশ মিনিট পর আপনার হাতে একটা চলমান app। দারুণ। কিন্তু এখন আপনি “view files”-এ ক্লিক করেছেন আর এমন একটা ফোল্ডার ট্রি-র দিকে তাকিয়ে আছেন যা দেখে মনে হয় অন্য কোনো ভাষায় লেখা। package.json কী জিনিস? node_modules-এ চল্লিশটা জিনিস কেন? “schema” মানে কী আর আপনার কাছে একটা আছেই বা কেন?

এই লেখাটা একটা গাইডেড ট্যুর। কোনো টিউটোরিয়াল নয় — একটা ট্যুর। পড়ার পর আপনি এই ফাইলগুলোর কোনোটাই নিজে লিখতে শিখবেন না, কিন্তু পরের বার যখন কিছু একটা অদ্ভুত দেখাবে, তখন আপনি জানবেন app-এর কোন কোণার দিকে আঙুল তুলতে হবে।

আমি পুরোটা জুড়ে তিনটে চলমান উদাহরণ ব্যবহার করব, যাতে বিমূর্ত অংশগুলোর সঙ্গে জুড়ে দেওয়ার মতো কিছু ঠোস থাকে:

• মায়া, একজন মার্কেটিং লিড, যিনি তাঁর টিমের জন্য একটা রেফারাল লিডারবোর্ড বানিয়েছেন।
• জর্ডান, একজন যোগব্যায়াম শিক্ষক, যিনি একটা ক্লাস booking সাইট বানিয়েছেন।
• স্যাম, যিনি একটা বেকারি চালান, যিনি একটা “আগামীকালের ক্রোসঁ আগেভাগে অর্ডার করুন” পেজ বানিয়েছেন।

তিনজনই একটা AI app builder ব্যবহার করেছেন। একজন কাস্টমারের চোখে তিনটে app একদম আলাদা দেখায়। ভেতরে, এগুলোর গড়ন আশ্চর্যজনকভাবে একই রকম।

frontend: আপনার কাস্টমার আসলে যা দেখে

frontend হলো সেই সব কিছু যা কারো ব্রাউজারে লোড হয়। বোতাম, লেআউট, ফন্ট, অ্যানিমেশন, একটা ফর্ম সাবমিট করার পর যেভাবে নিজেকে পরিষ্কার করে ফেলে — সবটাই। আপনি যদি এটা দেখতে পান, তবে এটা frontend।

মায়ার জন্য frontend হলো একটা লিডারবোর্ড, যাতে র‌্যাঙ্ক, নাম আর রেফারালের সংখ্যা আছে। জর্ডানের জন্য এটা একটা ক্লাসের ক্যালেন্ডার, যাতে একটা “book” বোতাম আছে। স্যামের জন্য এটা পেস্ট্রির একটা লিস্ট, যার প্রতিটার পাশে ছোট ছোট প্লাস-আর-মাইনাস বোতাম আছে।

প্রজেক্টের ভেতরে frontend সাধারণত app/, pages/ বা src/-এর মতো নামের একটা ফোল্ডারে থাকে। আপনি .tsx বা .jsx-এ শেষ হওয়া ফাইল দেখবেন। প্রতিটা মোটামুটি “একটা স্ক্রিন” বা “একটা স্ক্রিনের একটা অংশ”। লিডারবোর্ডের একটা সারি একটা ফাইল। হেডার আরেকটা ফাইল। যে পেজটা সবটা জুড়ে রাখে সেটা তৃতীয় একটা।

আপনি যখন AI builder-কে বলেন “বোতামগুলো আরও গোল করো” বা “লিডারবোর্ডটা ডানে সরাও”, তখন এই অংশটাই বদলায়।

backend: যে অংশটা চিন্তা করে

backend হলো সেই অংশ যা কেউ দেখে না, কিন্তু সবাই যার ওপর নির্ভর করে। এটা সেই কোড যা অন্য কোথাও চলে — কাস্টমারের ব্রাউজারে নয়, একটা সার্ভারে — যখন এমন কিছু ঘটার দরকার যা একা সামলানোর জন্য কাস্টমারের ব্রাউজারকে বিশ্বাস করা যায় না।

ব্রাউজার সবকিছু করতে পারে না কেন? কারণ ব্রাউজার হলো কাস্টমারের মেশিন, আর আপনি এটাকে বিশ্বাস করতে পারেন না। মায়ার লিডারবোর্ড যদি রেফারাল কাউন্ট কেবল ব্রাউজারেই আপডেট করত, তাহলে যে কেউ রাইট-ক্লিক করে নিজের নামে ৯,০০০ রেফারাল যোগ করে নিতে পারত। তাই backend-ই সেই জায়গা যেখানে নিয়মগুলো থাকে: “এই মানুষটা এটা করতে পারবে, কিন্তু ওটা নয়,” “এটা সত্যিই ডেটাবেসে সেভ করো,” “এই ইমেইলটা পাঠাও।”

backend সাধারণত api/, server/ বা app/api/ নামের একটা ফোল্ডারে থাকে। সেখানকার ফাইলগুলো সাধারণত ছোট। প্রতিটা একটা নির্দিষ্ট রিকোয়েস্ট সামলায়: “একটা booking তৈরি করো,” “আজকের ক্রোসঁগুলোর লিস্ট দাও,” “একটা রেফারাল যোগ করো।”

আপনার app-এ যখন কিছু একটা কাজ করে কিন্তু ফলাফলটা টেকে না — আপনি submit-এ ক্লিক করেন, একটা কনফার্মেশন দেখেন, কিন্তু পরদিন ডেটা গায়েব — তখন বাগটা প্রায় সবসময়ই backend-এ।

ডেটাবেস: আপনার app-এর স্মৃতি

আপনার app-এর স্মৃতিকে ফাইলিং ক্যাবিনেটের একটা সারি হিসেবে কল্পনা করুন। প্রতিটা ক্যাবিনেটের সামনে একটা লেবেল আছে। একটায় লেখা “users”। একটায় “bookings”। একটায় “croissant_orders”। প্রতিটা ক্যাবিনেটের ভেতরে প্রতিটা ড্রয়ার একটা সারি। প্রতিটা ড্রয়ারে একই সেট খোপ আছে: একটা নাম, একটা ইমেইল, একটা created_at, একটা status।

ওই কাঠামো — “কোন ক্যাবিনেটগুলো আছে, প্রতিটা সারিতে কী কী খোপ আছে” — তাকে বলা হয় একটা schema। এটা প্রজেক্টের সবচেয়ে গুরুত্বপূর্ণ ফাইল, যদিও সম্ভবত এটাই দেখতে সবচেয়ে বিরক্তিকর। schema.ts, schema.prisma নামের একটা ফাইল, কিংবা db/ বা migrations/ নামের কোনো ফোল্ডারের ভেতরের কিছু খুঁজুন। এটা খুলুন। আপনি একটা লিস্ট দেখবেন, যা আপনার app আসলে দুনিয়া সম্পর্কে যা মনে রাখে তার প্রতিফলন।

জর্ডানের schema-তে একটা classes টেবিল, একটা bookings টেবিল আর একটা users টেবিল আছে। স্যামেরটায় আছে products, orders আর order_items। মায়ারটায় আছে members আর referrals। schema-র গড়নই হলো প্রোডাক্টের গড়ন, আর সেই কারণেই পরে এটা বদলানো বোতামগুলো দেখতে কেমন তা বদলানোর চেয়ে কঠিন।

একটা কাজের কৌশল: আপনার app কী মনে রাখে তা যদি সহজ ভাষায় বর্ণনা করতে পারেন, তাহলে সাধারণত schema-টাও বর্ণনা করতে পারবেন। “আমি প্রতিটা কাস্টমারের নাম আর ইমেইল মনে রাখি। প্রতিটা কাস্টমারের জন্য, তারা যে অর্ডারগুলো দিয়েছে সেগুলো মনে রাখি। প্রতিটা অর্ডারের জন্য, কোন পেস্ট্রিগুলো আর প্রতিটার কয়টা মনে রাখি।” ওই বাক্যটাই, প্রায় শব্দে শব্দে, হলো schema।

auth: দরজায় দাঁড়ানো দারোয়ান

“auth” হলো দুটো শব্দ একসঙ্গে মেশানো: authentication (আপনি কে?) আর authorization (আপনার কী করার অনুমতি আছে?)। দুটোই সাধারণত auth/ নামের একটা ফোল্ডারের অল্প কিছু ফাইল দিয়ে সামলানো হয়, কিংবা এমন একটা সার্ভিস দিয়ে যার নাম আপনি হয়তো চেনেন: Clerk, Auth0, Supabase Auth, NextAuth।

দুটো প্রশ্ন আলাদা। Authentication-এর উত্তর: “এটা কি সত্যিই মায়া?” — সাধারণত একটা পাসওয়ার্ড, একটা Google login, কিংবা তাঁকে ইমেইল করা একটা ম্যাজিক লিংক দিয়ে। Authorization-এর উত্তর: “মায়ার কি অন্য মানুষের রেফারাল ডিলিট করার অনুমতি আছে?” — আর বেশিরভাগ AI দিয়ে বানানো app-এর জন্য প্রথম সপ্তাহে সৎ উত্তরটা হলো “আমরা চেক করতে ভুলে গেছি।”

এটাই সেই অংশ যা সবচেয়ে বেশি নীরবে ভাঙা থাকে। login স্ক্রিন কাজ করে, তাই মনে হয় নিরাপদ। কিন্তু backend সবসময় চেক করে না যে যিনি লগ ইন করেছেন তিনিই সেই ব্যক্তি যাঁর ডেটা পড়ার চেষ্টা করা হচ্ছে। আপনার app-এ যদি “আমার ডেটা বনাম তোমার ডেটা”-র কোনো ধারণা থাকে, AI builder-কে স্পষ্ট করে জিজ্ঞেস করুন: “নিশ্চিত করো যেন ইউজাররা কেবল নিজেদের ডেটাই দেখতে আর এডিট করতে পারে।” ওই একটা বাক্য কত ঘন ঘন একটা অনুপস্থিত চেক ফাঁস করে দেয়, তা দেখে আপনি অবাক হবেন।

integration: যা আপনি বানাননি কিন্তু তবু ব্যবহার করছেন

এখানেই বেশিরভাগ নন-ডেভেলপার আসলে কী ঘটছে তা কম করে আঁচ করেন। স্যামের “আপনার ক্রোসঁ তৈরি” ইমেইলটা যেটা পাঠায় সেটা কোনো কোড নয় — সেটা SendGrid বা Resend-এ একটা অ্যাকাউন্ট। জর্ডানের ক্লাসের পেমেন্ট যেটা প্রসেস করে সেটা কোনো কোড নয় — সেটা Stripe। মায়ার লিডারবোর্ডের ছবিগুলো যেটা হোস্ট করে সেটা কোনো কোড নয় — সেটা S3 বা Cloudinary-র মতো একটা স্টোরেজ সার্ভিস।

প্রতিটা integration দুটো জায়গায় দেখা দেয়। backend-এ একটা ছোট কোডের টুকরো থাকে যা বলে “এই Stripe, এই কার্ডটা চার্জ করো।” আর একটা key থাকে — একটা লম্বা গোপন স্ট্রিং — যা কোনো নিরাপদ জায়গায় (সাধারণত .env নামের একটা ফাইল, যেটা কারো কখনো কমিট করা উচিত নয়) সংরক্ষিত থাকে, যা Stripe-কে প্রমাণ করে যে রিকোয়েস্টটা স্যামের বেকারি থেকেই এসেছে, কোনো অপরিচিত কারো কাছ থেকে নয়।

আপনার app যদি কখনো হঠাৎ ইমেইল পাঠানো বন্ধ করে দেয় বা পেমেন্ট নেওয়া বন্ধ করে দেয়, কারণটা প্রায় সবসময়ই এর একটা: একটা মেয়াদোত্তীর্ণ key, একটা ছুঁয়ে ফেলা ব্যবহার সীমা, কিংবা integration-এর নীতিতে একটা পরিবর্তন। কোড ভাঙেনি। হাতমেলানোটা ভেঙেছে।

deploy: এটা কীভাবে ইন্টারনেটে পৌঁছায়

শেষ অংশটা হলো সেই অংশ যা আপনার ডিস্কের ফোল্ডারটাকে এমন একটা জিনিসে বদলে দেয় যা আপনার কাস্টমার একটা URL-এ গিয়ে দেখতে পারে। এর সাধারণত মানে তিনটে ছোট জিনিস একসঙ্গে কাজ করা:

• host: Vercel, Netlify, Fly বা Render-এর মতো একটা সার্ভিস যা আপনার backend চালায় আর আপনার frontend পরিবেশন করে।
• domain: mayas-leaderboard.com-এর মতো একটা নাম যা আপনার host-এর দিকে ইশারা করে।
• build: সেই রেসিপি যা আপনার এলোমেলো সোর্স ফাইলগুলো নিয়ে সেগুলোকে এমন একটা হালকা, দ্রুততর সংস্করণে বদলে দেয় যা আসলে চলে।

যখন কিছু একটা লোকালি কাজ করে কিন্তু প্রোডাকশনে ভেঙে পড়ে, তখন গণ্ডগোলটা সাধারণত এখানে। এমন একটা key যা আপনার ল্যাপটপে সেট করা কিন্তু host-এ নেই। এমন একটা লাইব্রেরি যা ডেভেলপমেন্টে ইনস্টল করা কিন্তু প্রোডাকশনে নয়। এমন একটা ডেটাবেস যা আপনার ব্রাউজারে আছে কিন্তু লাইভ সাইটে নেই।

পাঁচ-মিনিটের অভ্যাস যা নিজের খরচ নিজেই তুলে আনে

আপনাকে আপনার প্রজেক্টের প্রতিটা ফাইল পড়তে হবে না। সেগুলোর বেশিরভাগ কী করে তা জানার দরকার নেই। কিন্তু সপ্তাহে একবার একটা পাঁচ-মিনিটের ঘুরে দেখা করা উচিত, যেখানে আপনি ওপরের প্রতিটা ফোল্ডার খুলে AI builder-কে সহজ ভাষায় জিজ্ঞেস করেন, কী বদলেছে।

মায়া প্রতি শুক্রবার বিকেলে এটা করেন। তিনি টাইপ করেন: “এই সপ্তাহে schema-তে কী বদলেছে, আর কেন?” আর: “এই app-এ কি এমন কোনো নতুন integration আছে যা আমি চাইনি?” উত্তরগুলো প্রায় সবসময়ই আশ্বস্তকর। যে কয়েকবার নয়, সেই কয়েকবার তিনি সমস্যাগুলো ছোট থাকতেই ধরে ফেলেন।

অংশগুলো বোঝার পুরো উদ্দেশ্য এটাই। একজন ডেভেলপার হয়ে ওঠা নয়। শুধু আরও ভালো প্রশ্ন জিজ্ঞেস করতে পারা।

এরপর কোথায় যাবেন

এই ট্যুর কাজে লেগে থাকলে, দুটো ফলো-আপ আপনার সময়ের যোগ্য। ‘দেখতে তো ঠিকই লাগছে’ বাগ আলোচনা করে এই অংশগুলোর একটা যখন নীরবে ভাঙা থাকে তখন কী করবেন, আর demo-ready বনাম production-ready আলোচনা করে কীভাবে বুঝবেন যে আপনার app প্রথম ধাপ থেকে দ্বিতীয় ধাপে চলে গেছে। একই মানচিত্র, ভিন্ন কাজে লাগানো।