Go ও PostgreSQL বনাম Node.js ও Supabase: পার্থক্য কোথায়

একটি AI জেনারেটর যেকোনো স্ট্যাকেই বিশ্বাসযোগ্য SaaS প্রোটোটাইপ তৈরি করতে পারে। আসল পার্থক্য বোঝা যায় গ্রাহক অস্বস্তিকর ডেটা তৈরি করার পর, রিট্রাই এলোমেলো ক্রমে এলে, কুয়েরি প্ল্যান বদলালে এবং কাউকে প্রোডাকশনের ব্যর্থতা ব্যাখ্যা করতে হলে। যে স্ট্যাকের ব্যর্থতার ধরন আপনার দল দেখতে ও ঠিক করতে পারে, সেটিই বেছে নিন। প্রথম স্ক্রিনটি সবচেয়ে দ্রুত বানিয়েছে কোনটি, সেটি নয়।

PostgreSQL-সহ Go আপনাকে অ্যাপ্লিকেশন ও ডেটাবেসের স্পষ্ট সীমানা দেয়। অনুরোধ কীভাবে ঢুকবে, ট্রানজ্যাকশন কোথায় শুরু হবে, SQL কেমন হবে এবং বাইনারি কীভাবে চলবে, তা আপনি ঠিক করেন। Supabase-সহ Node.js আপনাকে JavaScript বা TypeScript রানটাইমের সঙ্গে PostgreSQL-কেন্দ্রিক ম্যানেজড সার্ভিসের একটি সংগ্রহ দেয়, যার মধ্যে প্রমাণীকরণ, স্টোরেজ, রিয়েলটাইম ফিচার, generated API এবং হোস্টেড অপারেশনস রয়েছে। দ্বিতীয় বিকল্পটি অনেক সেটআপের কাজ কমায়, কিন্তু অ্যাপ্লিকেশন লজিক কোথায় থাকবে এবং কোন অপারেশনাল সিদ্ধান্ত আপনার, সেটিও বদলে দেয়।

এগুলো দুটি সমমানের প্রোগ্রামিং ভাষার প্যাকেজ নয়। একটি সাধারণত পরিকল্পনা করে জোড়া দেওয়া ব্যাকএন্ড, অন্যটি প্রায়ই ম্যানেজড পণ্যভিত্তিক আর্কিটেকচার। সিনট্যাক্স তুলনা করা বা তৈরি হওয়া ফাইল গোনা এই সিদ্ধান্ত ধরতে পারে না।

দুই স্ট্যাকে দায়িত্ব কীভাবে ভাগ হয়

প্রথম সিদ্ধান্ত হলো, ব্যাকএন্ডের চুক্তির কতটা আপনি নিজে নিয়ন্ত্রণ করতে চান। Go ও PostgreSQL-এ আপনার সার্ভিস সাধারণত HTTP হ্যান্ডলিং, অনুমতির সিদ্ধান্ত, ভ্যালিডেশন, ট্রানজ্যাকশনের সীমানা, ব্যাকগ্রাউন্ড কাজ ও ডেটাবেস অ্যাক্সেসের মালিক। PostgreSQL স্থায়ী অবস্থা ও ডেটাবেসের নিশ্চয়তার মালিক। হোস্টিং, পরিচয়, অবজেক্ট স্টোরেজ ও ডিপ্লয়মেন্ট আলাদা সিদ্ধান্তই থাকে, যদি না আপনি সেগুলো যোগ করেন।

Node.js ও Supabase অ্যাপ্লিকেশন এসব দায়িত্ব ভাগ করে দেয়। Node সার্ভিস বা serverless function-এ কাস্টম লজিক থাকতে পারে, আর Supabase দেয় হোস্টেড PostgreSQL, Auth, Storage, Realtime, Edge Functions এবং ডেটাবেস থেকে তৈরি API স্তর। কখনও ব্রাউজার ক্লায়েন্ট Row Level Security (RLS) মেনে সরাসরি Supabase-এ কথা বলতে পারে। এতে সাধারণ endpoint কোড বাদ যায়, কিন্তু তখন ডেটাবেস পলিসি অ্যাপ্লিকেশনের প্রকাশ্য সীমানার অংশ হয়।

এই পার্থক্য Go বনাম TypeScript-এর চেয়েও গুরুত্বপূর্ণ। Go-তে generated REST handler এবং Supabase-এর generated table call দুটিই সমান দ্রুত মনে হতে পারে। কিন্তু Go handler-এ অনুরোধ দেখা, নিয়ম প্রয়োগ, ট্রানজ্যাকশন খোলা ও ট্রেস বের করার একটি স্পষ্ট জায়গা থাকে। সরাসরি table call ডেটায় পৌঁছানোর আগে generated API আচরণ ও RLS পার হতে পারে। সোর্স কোডে সেই পথটি ছোট, প্রোডাকশনে যে সহজ হবে এমন নয়।

ম্যানেজড ফিচারকে বিনা খরচের আনুষঙ্গিক সুবিধা নয়, আর্কিটেকচারগত অঙ্গীকার হিসেবে দেখুন। Auth যে পরিচয় দেয় RLS যদি সেটিই ব্যবহার করে, Storage পলিসি একই পরিচয়ের উল্লেখ করে এবং Realtime subscription ডেটাবেস পরিবর্তনের ওপর নির্ভর করে, তবে পরে এক অংশ বদলালে কয়েকটি চুক্তিতে প্রভাব পড়ে। এই সংযোগ একদমই যুক্তিসঙ্গত হতে পারে। ছোট দল প্রায়ই সেবা-সমূহের সুসংহত সেট কিনে লাভবান হয়। সমস্যা হয় যখন দল ভাবে, তারা শুধু একটি ডেটাবেস বেছে নিয়েছে।

জেনারেটর যদি repository, service layer ও generic helper-এ ভরা অভ্যন্তরীণ framework বানায়, তবে Go ও PostgreSQL-ও নির্ভরতা আড়াল করতে পারে। ইঞ্জিনিয়াররা কোডের পথ অনুসরণ করতে পারলেই মালিকানা কাজে লাগে। generated abstraction সাধারণ SQL update-ও RLS পলিসির চেয়ে খুঁজে পাওয়া কঠিন করে দিতে পারে। জেনারেটরকে সবচেয়ে ছোট ও পাঠযোগ্য সীমানা চাইতে বলুন, তারপর আরেকটি স্তর যোগের আগে ফলটি দেখুন।

ওয়ার্কলোডের ধরনই রানটাইম ঠিক করবে

টেকসই সমসাময়িক কাজ, মিশ্র ব্যাকগ্রাউন্ড কাজ, পূর্বানুমানযোগ্য মেমরি চাহিদা এবং একাধিক সমন্বিত অপারেশনের ওপর latency নির্ভর এমন endpoint-এ Go মানায়। Goroutine সমসাময়িক I/O সহজ করে, আর compiled binary অপারেটরদের জন্য ছোট একটি ডিপ্লয়মেন্ট ইউনিট দেয়। এতে প্রতিটি Go সার্ভিস দ্রুত হয়ে যায় না। খারাপ SQL, সীমাহীন concurrency এবং অনুপস্থিত timeout পরিচিতভাবেই ব্যর্থ হয়।

নেটওয়ার্ক I/O, ছোট request handler, event processing এবং TypeScript-এ আগে থেকেই দক্ষ দল-নির্ভর ওয়ার্কলোডে Node.js মানায়। এর event loop অপেক্ষমাণ অনেক connection দক্ষতার সঙ্গে সামলায়। CPU-নিবিড় কাজ মূল thread-এ চললে অগ্রগতি আটকে যায়। তাই image transform, বড় document parsing বা local model-সংক্রান্ত গণনার জন্য worker thread, আলাদা worker বা অন্য সার্ভিস লাগে। demo input ছোট হওয়ায় generated code প্রায়ই এই সীমাটি উপেক্ষা করে।

সাধারণ ডেটা অ্যাক্সেস, প্রমাণীকরণ প্রবাহ, ফাইল স্টোরেজ এবং ডেটাবেসভিত্তিক realtime update-এ Supabase অ্যাপ্লিকেশনের কাজ কমাতে পারে। প্রথম সংস্করণে যেখানে মূলত account, form, record, permission ও notification থাকে, সেখানে এটি শক্তিশালী পছন্দ। প্রতিটি অপারেশনে বহু বাইরের সিস্টেম সমন্বয় করতে হলে, দীর্ঘস্থায়ী job লাগলে, বা domain rule ডেটাবেস পলিসি কিংবা ছোট edge function-এ মানানসই না হলে এটি দুর্বল পছন্দ।

বেছে নেওয়ার আগে ওয়ার্কলোড নিয়ে চারটি প্রশ্ন করুন:

• একজন ব্যবহারকারীর একটি কাজ কি এক রেকর্ডে অপারেশন, নাকি কয়েকটি aggregate জুড়ে ট্রানজ্যাকশন?
• অনুরোধগুলো কি মূলত নেটওয়ার্কের জন্য অপেক্ষা করবে, নাকি উল্লেখযোগ্য CPU কাজ করবে?
• job কি HTTP request-এর চেয়ে বেশি সময় চলবে এবং retry, lease, cancellation বা অগ্রগতি ট্র্যাকিং চাইবে?
• ডেটাবেস কি অনুমতি সহজে প্রকাশ করতে পারে, নাকি অনুমতি বাইরের অবস্থা ও workflow history-র ওপর নির্ভরশীল?

একটি billing import এই বিভাজনটি দেখায়। ফাইল আপলোড, তার metadata রাখা এবং অগ্রগতি দেখানো দুই স্ট্যাকেই সম্ভব। হাজার হাজার অনিয়মিত সারি parse করা, বর্তমান invoice-এর সঙ্গে deduplicate করা, account-নির্দিষ্ট নিয়ম প্রয়োগ করা এবং আংশিক ব্যর্থতার পর আবার শুরু করতে স্পষ্ট job model লাগে। এই worker-এর জন্য Go স্বচ্ছন্দ। দল CPU কাজ আলাদা রাখলে এবং স্থায়ী queue থাকলে Node-ও কার্যকর। Supabase ডেটাবেস ও storage স্তর হিসেবে উপকারীই থাকে, কিন্তু job-এর অর্থবিধি মিলিয়ে দেয় না।

শুধু পারফরম্যান্স গুরুত্বপূর্ণ হতে পারে বলে Go বেছে নেবেন না। বেশিরভাগ নতুন SaaS-এ runtime throughput সীমাবদ্ধ হওয়ার আগে কুয়েরি, পণ্য ও অপারেশনাল ভুল দেখা দেয়। সার্ভিসের ধরন স্পষ্ট concurrency এবং দীর্ঘস্থায়ী process থেকে লাভবান হলে Go নিন। আবার AI model TypeScript অনর্গল তৈরি করে বলেই Node নেবেন না। ওয়েব সীমানাজুড়ে এক ভাষা ব্যবহার করে ওয়ার্কলোড এবং যারা তা চালাবে তারা লাভবান হলে Node নিন।

দলের দক্ষতা generated code-এর খরচ বদলায়

সেরা স্ট্যাক হলো, জেনারেটর ভুল করলে যে স্ট্যাক আপনার দল ডিবাগ করতে পারে। reviewer যদি lost update, অনিরাপদ পলিসি বা কখনও await না হওয়া promise চিনতেই না পারে, তবে generation speed-এর মূল্য কম।

Go প্রোডাকশনের অভিজ্ঞ দল সাধারণত explicit handler, typed domain structure, context.Context cancellation এবং সরাসরি SQL পছন্দ করবে। Go compiler wiring-এর এক ধরনের ভুল ধরে, কিন্তু কোনো transaction সঠিক সারিকে রক্ষা করছে কি না বা authorization check ব্যবসায়িক নিয়মের সঙ্গে মেলে কি না, তা প্রমাণ করতে পারে না। reviewer-এর ডেটাবেস বোঝাপড়া তবু দরকার।

TypeScript-কেন্দ্রিক দল Node ও Supabase codebase-এ দ্রুত এগোতে পারে, কারণ frontend ও backend type পরিচিত tool ব্যবহার করে। schema-ই উৎস হলে Supabase-generated database type editor-এ ভালো feedback দেয়। type একা runtime validation বাধ্যতামূলক করে না, আর type assertion সেই সতর্কতাই চুপ করিয়ে দিতে পারে যা reviewer-এর প্রয়োজন ছিল। generated code-এর প্রায়ই ধরে নেওয়ার অভ্যাস থাকে যে বাইরের input আগেই কাঙ্ক্ষিত গঠনের।

দক্ষতার মধ্যে দলের অপারেশনাল শব্দভাণ্ডারও আছে। কেউ কি অনুমান না করে EXPLAIN (ANALYZE, BUFFERS) পড়তে পারে? কেউ কি RLS-এর USING expression ও WITH CHECK expression আলাদা করতে পারে? কেউ কি rejected promise পেরিয়ে asynchronous Node handler trace করতে পারে? কেউ কি Go connection pool saturation দেখে cancellation ছড়িয়ে দিতে পারে? যে স্ট্যাকে বেশি প্রশ্নের উত্তর হ্যাঁ হয়, তার অপারেশনাল ঝুঁকি কম।

ছোট দলকে context switching গুনতে হবে। Go ও PostgreSQL-এ migration, authentication, storage, queue, observability এবং hosting-এর জন্য আলাদা পছন্দ লাগতে পারে। প্রতিটি পছন্দ ভালো হলেও integration-এর কাজ বাড়ায়। Node ও Supabase এই পৃষ্ঠের বড় অংশ একটি পণ্যে কেন্দ্রীভূত করে এবং TypeScript-কে frontend-এর কাছেই রাখে। বাঁচানো মনোযোগ বাস্তব সুবিধা।

এর বিপরীত খরচ বিশেষজ্ঞ জ্ঞান। RLS-সহ সরাসরি browser access প্রত্যেক reviewer-কে database policy-কে application authorization হিসেবে বুঝতে বলে। Edge function প্রচলিত Node server থেকে আলাদা runtime boundary আনে। hosted dashboard নিয়মিত কাজ সহজ করে, কিন্তু versioned migration-এর বাইরে গিয়ে production state বদলানোর প্রলোভনও দিতে পারে। এসবের কোনোটিই Supabase বাতিল করার কারণ নয়। হিসাবের মধ্যে রাখুন।

দলের কেউ যদি কোনো স্ট্যাকই আগে চালিয়ে না থাকে, তবে কম স্বাধীন moving part-সহ নকশা বেছে নিন এবং বেরিয়ে আসার পথ লিখে রাখুন। রেকর্ডভিত্তিক SaaS-এর জন্য সেটি প্রায়ই Supabase। job, integration ও custom workflow-কেন্দ্রিক backend-এ client call, policy, function ও trigger-এ ছড়ানো লজিকের চেয়ে managed PostgreSQL-সহ ছোট Go service নিয়ে ভাবা সহজ হতে পারে।

কুয়েরি নিয়ন্ত্রণই পণ্যের নিয়ন্ত্রণে পরিণত হয়

SQL-এর গঠন ও transaction behavior পণ্যের কেন্দ্রে হলে সরাসরি PostgreSQL access-সহ Go নিন। সাধারণ CRUD প্রাধান্য পেলে এবং RLS নিরাপত্তা মডেলকে জটিলতা ছাড়া প্রকাশ করতে পারলে Supabase-এর generated data access নিন।

PostgreSQL-এর ডকুমেন্টেশন transaction isolation নিয়ে স্পষ্ট: Read Committed default, এবং একটি transaction-এ পরপর দুই command ভিন্ন committed data দেখতে পারে। দল প্রায়ই স্বস্তিদায়ক এই কথাটি বলে যে transaction অপারেশনকে নিরাপদ করে, অথচ isolation level ও locking behavior নির্দিষ্ট করে না। Transaction কাজকে একসঙ্গে রাখে। সব race নিজে থেকে ঠেকায় না।

ধরা যাক, দুটি worker পরের pending export claim করতে চায়। আগে read, পরে update করলে দুজনেই একই row দেখতে পারে। claim-টিকে একটি database operation করুন এবং ইচ্ছাকৃতভাবে locking ব্যবহার করুন:

BEGIN;

WITH next_job AS (
  SELECT id
  FROM export_jobs
  WHERE status = 'pending'
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
UPDATE export_jobs AS j
SET status = 'running',
    started_at = now(),
    worker_id = $1
FROM next_job
WHERE j.id = next_job.id
RETURNING j.id, j.account_id, j.payload;

COMMIT;

ফল হয় id, account_id ও payload-সহ একটি claimed row, অথবা job না থাকলে শূন্য row। queue-ধাঁচের consumer ভিন্ন row নিতে পারলে SKIP LOCKED উপযুক্ত। user-facing read-এর সাধারণ সমাধান এটি নয়, কারণ এটি ইচ্ছা করেই locked row বাদ দেয়।

Go-তে এই statement explicit transaction ও cancellation deadline-সহ repository বা query package-এ থাকতে পারে। Node-এ server-side database client সমমানের function বা SQL call চালাতে পারে। generated Supabase API-এ জটিল locking logic সাধারণত RPC-এর মাধ্যমে উন্মুক্ত করা PostgreSQL function-এ যায়। সেটিও শক্ত PostgreSQL, কিন্তু reviewer-কে request handler নয়, migration ও database function-এ দেখতে জানতে হবে।

RLS-ও একই নির্ভুলতা চায়। PostgreSQL প্রতিটি table ও command অনুযায়ী policy মূল্যায়ন করে। USING clause নির্ধারণ করে command বিদ্যমান কোন row দেখতে পাবে, আর WITH CHECK নির্ধারণ করে কোন নতুন বা বদলানো row তৈরি করতে পারবে। শুধু read filter করা policy insert ও update-এর সব invariant নিজে থেকে প্রকাশ করে না। অন্তত anonymous identity, সাধারণ member, অন্য tenant-এর member ও privileged service role দিয়ে policy পরীক্ষা করুন।

generated CRUD আকর্ষণীয়, কারণ এটি পুনরাবৃত্তিমূলক endpoint code মুছে দেয়। যে কাজের চুক্তি সত্যিই table-আকৃতির, সেখানে এটি রাখুন। বহু record-জুড়ে invariant, idempotency এবং workflow transition server boundary বা সতর্কভাবে নকশা করা database function-এর পেছনে রাখুন। কোনো product rule বোঝাতে একটি অনুচ্ছেদ লাগলে, সেটিকে client code ও কয়েকটি RLS policy-তে ছড়িয়ে দিলে পরের incident দীর্ঘ হবে।

আপনি যে সীমানা রাখেন, পোর্টেবিলিটি তার ওপর নির্ভর করে

Go ও PostgreSQL সাধারণত ডিপ্লয়মেন্ট থেকে বেরিয়ে আসার স্পষ্ট পথ দেয়, কারণ application একটি binary এবং database standard PostgreSQL protocol-এ কথা বলে। service container-এ বা সরাসরি host-এ চালিয়ে বহু PostgreSQL provider থেকে বেছে নিতে পারেন। তবু provider-নির্দিষ্ট extension, অঘোষিত infrastructure ও environment assumption এড়ানোর ওপর পোর্টেবিলিটি নির্ভর করে।

Supabase PostgreSQL ব্যবহার করে, তাই proprietary database-এর তুলনায় data বের করার পথ অনেক ভালো। database dump table, index, function, trigger এবং policy model-এর বড় অংশ সংরক্ষণ করতে পারে। পুরো application-টি অবশ্য Auth token claim, Storage object convention, Realtime behavior, edge function, generated API semantics, secret ও deployment configuration-এর ওপরও নির্ভর করতে পারে। database সরানো আর system সরানো এক কথা নয়।

launch-এর আগে portability inventory তৈরি করুন। প্রতিটি dependency-কে database, identity, file, asynchronous work, runtime ও deployment-এর অধীনে লিখুন। প্রতিটির জন্য আপনার code যে contract ব্যবহার করে এবং তা বদলানোর খরচ লিখুন। কাজে লাগে এমন প্রশ্ন migration সম্ভব কি না নয়। যথেষ্ট সময় দিলে প্রায় সবই সম্ভব। জিজ্ঞেস করুন, স্বাভাবিক একটি release team কি product-এর কাজ চালিয়ে যেতে যেতে এটি সরাতে পারবে?

AI-তৈরি SaaS-এ source export গুরুত্বপূর্ণ, কারণ তৈরি করা application কাজে লাগবে তখনই যখন আপনি নিজের জিনিস দেখতে ও চালাতে পারবেন। Koder.ai source code export-এর পাশাপাশি deployment ও hosting সমর্থন করে, ফলে দল generation-কে অস্বচ্ছ endpoint না ধরে তৈরি করা React ও Go/PostgreSQL application পর্যালোচনা করতে পারে। এতে generation environment-এর বাইরে clean build পরীক্ষা করার প্রয়োজন শেষ হয় না।

সেই clean build আগে করুন। খালি machine বা ন্যূনতম container থেকে শুরু করুন, migration দিয়ে database restore করুন, নথিভুক্ত environment variable দিন, test চালান এবং একটি representative request serve করুন। এরপর nonproduction environment-এ বাস্তব backup থেকে restore করুন। vendor change বা outage-এর সময় পোর্টেবিলিটি পরীক্ষা করতে বসা দল ইতিমধ্যেই ব্যয়বহুল সিদ্ধান্ত নিয়েছে।

data location-ও পোর্টেবিলিটি নির্ধারণ করতে পারে। চুক্তিতে নির্দিষ্ট দেশে application চালানো বাধ্যতামূলক হলে runtime, database, backup, log, object storage ও support access সবই সে শর্ত মানে কি না যাচাই করুন। শুধু web process সরালে data system সরে না। data privacy ও cross-border transfer-এর প্রয়োজনে Koder.ai ভিন্ন দেশে application চালাতে পারে, তবু দলকে নিজেদের architecture-এর প্রতিটি data-bearing component-এর মানচিত্র করতে হবে।

ডিবাগিং দেখায় জটিলতা কোথায় গেছে

Go ও PostgreSQL-এ debugging সাধারণত request trace, service log, database session ও job worker-এ কেন্দ্রীভূত থাকে। Node.js ও Supabase-এ একই তদন্ত browser call, Node process বা edge function, generated API log, Auth, RLS, Realtime ও PostgreSQL-এ ছড়িয়ে পড়তে পারে। application code-এর লাইন কম হলে দেখার সীমানা বাড়তেও পারে।

একটি সাধারণ schema change থেকে পরিচিত failure শুরু হয়। generated application nullable organization_id যোগ করে, কিছু row backfill করে, RLS policy চালু করে এবং client query বদলায়। happy-path account কাজ করে। পুরোনো কোনো row null-ই থাকে, তাই policy সেটি লুকিয়ে ফেলে। client স্পষ্ট authorization error-এর বদলে empty result পায় এবং blank state দেখায়। একটি realtime subscription আলাদা filter ব্যবহার করে এবং পরিবর্তনের ঘোষণা দিতে থাকে। support দেখে, refresh-এর পর কখনও কখনও screen আবার ভরে যায়।

এই শৃঙ্খলের কিছুই অস্বাভাবিক নয়। কঠিন হলো প্রতিটি সিদ্ধান্ত পর্যবেক্ষণ করা। তদন্তকারীর দরকার authenticated subject, token claim, request identifier, database role, SQL বা generated API operation, policy outcome, row count, subscription channel এবং deployed schema version। এসব তথ্য যদি একটি অভিন্ন request বা user correlation value ছাড়া ভিন্ন dashboard-এ থাকে, তবে দল timestamp মিলিয়ে incident পুনর্গঠন করে।

প্রচলিত Go endpoint query করার আগেই অনুপস্থিত organization-কে domain error বানাতে পারে, এরপর একটি structured event log করে নির্ধারিত status ফেরায়। এই স্পষ্টতা উপকারী। তবে ধরে নেওয়া হয় handler-ই table-এ যাওয়ার একমাত্র পথ। ভুলে যাওয়া admin endpoint বা worker একই authorization এড়িয়ে যেতে পারে, যদি database একই invariant বলবৎ না করে।

Supabase নকশা প্রতিটি client path-এর জন্য PostgreSQL-এ tenant isolation বলবৎ করতে পারে। এটিও উপকারী। এর failure mode হলো policy অদৃশ্যতা: empty row set সঠিক filtering, ভুল identity context, অসম্পূর্ণ migration data বা query bug, যেকোনোটি হতে পারে। production-এ RLS বন্ধ না করেই এই ক্ষেত্রগুলো আলাদা করতে পারে এমন diagnostic operation তৈরি করুন।

দুই স্ট্যাকেই প্রতিটি generated backend path-এ চারটি field চাইুন: correlation identifier, authenticated actor identifier, operation name এবং schema বা release version। যেখানে sensitive data প্রকাশ হয় না, সেখানে duration ও row count রেকর্ড করুন। client-এর জন্য নিরাপদ response-এ map করার সময় মূল error cause রাখুন। Node-এ request boundary-তে rejected promise handle করুন এবং process-level handler-কে recovery ভাববেন না। Go-তে database call-এ request context দিন এবং deadline cancellation ও database failure আলাদা করুন।

ডিবাগ করা যায় কি না, সেটিও নকশার বৈশিষ্ট্য। জেনারেটর এমন code বানালে যা অপারেটর trace করতে পারে না, সবখানে log যোগ করতে বলার আগে control flow সহজ করতে বলুন।

ডিপ্লয়মেন্টের সুবিধা ও অপারেশনাল মালিকানা আলাদা

প্রথম operational round-এ Supabase সাধারণত এগিয়ে থাকে। দল project provision করেই প্রতিটি component জোড়া না লাগিয়ে database ও integrated service পায়। backup, upgrade, service availability ও platform monitoring-এ managed default বা product control থাকে। retention ও limit বদলাতে পারে বলে সঠিক তথ্যের জন্য বর্তমান plan ও provider documentation পড়ুন।

ম্যানেজড মানে নজরদারি ছাড়াই চলবে নয়। application team এখনও schema design, index, ব্যয়বহুল query, connection behavior, data retention, RLS-এর সঠিকতা, secret, application monitoring এবং recovery test-এর মালিক। quota এবং কোন failure-এ provider support লাগবে তাও বুঝতে হবে। database healthy বলা dashboard বলতে পারে না যে একটি tenant-এর report ভুলবশত sequential scan করছে।

Go ও PostgreSQL-এ মালিকানা বেশি দৃশ্যমান। managed PostgreSQL নিলে provider database-এর অনেক যন্ত্রপাতি সামলাতে পারে, আর আপনার দল service runtime-এর মালিক থাকে। দুটিই নিজে host করলে patching, failover, backup, restore drill, capacity ও incident response-ও আপনার। self-hosting গম্ভীরতার ব্যাজ নয়। এর জন্য মানুষ ও মহড়া দরকার।

connection management দুই স্ট্যাকেই ধরা পড়ে। দীর্ঘস্থায়ী Go service pool ব্যবহার করে এবং open ও idle connection, connection lifetime ও request deadline-এ স্পষ্ট limit চায়। serverless Node function সঠিক pooler ব্যবহার না করলে এবং transaction-mode limitation না মানলে PostgreSQL সামলাতে না পারা client burst তৈরি করতে পারে। প্রতিটি request-এ নতুন client খোলা generated code demo পার করে দিতে পারে, traffic spike-এ ভেঙে পড়ে।

migration-এর একটি কর্তৃপক্ষ দরকার। নিয়ন্ত্রিত deployment step থেকে ordered, versioned migration চালান। startup-এ প্রতিটি service instance-কে schema বদলাতে দৌড়াতে দেবেন না এবং dashboard edit-কে অঘোষিত production truth হতে দেবেন না। expand-and-contract change deployment coupling কমায়: compatible column বা table যোগ করুন, দুই shape সামলাতে পারে এমন code deploy করুন, backfill করুন, read বদলান, তারপর পরের release-এ পুরোনো shape সরান।

restore সফল হওয়ার পরই backup-এর মূল্য আছে। isolated environment-এ restore schedule করুন এবং application-level fact যাচাই করুন: user authenticate করতে পারে, tenant boundary অটুট থাকে, file এখনও database reference-এর সঙ্গে মেলে, scheduled job দুইবার চলে না এবং একটি representative workflow সম্পন্ন হয়। এ কাজ দুই স্ট্যাকেই আছে। managed option backup machinery কে চালায় তা বদলায়, recovered product ঠিক হয়েছে কি না ঠিক করার দায়িত্ব বদলায় না।

প্রোটোটাইপের গতি ভুল প্রমাণ তৈরি করতে পারে

প্রথম prototype মাপে, generator-কে যে পথ বানাতে বলা হয়েছিল সেটি stack কত দ্রুত সামলায়। contention, partial failure, policy evolution, restore বা ছয় মাস পর নতুন engineer-এর তদন্ত stack কীভাবে সামলায়, তা মাপে না।

Node.js ও Supabase প্রায়ই বিশ্বাসযোগ্য record-oriented product-এর পথে ছোট রাস্তা দেয়। আলাদা vendor বাছাই ও integration ছাড়াই authentication, database access, storage ও realtime behavior পাওয়া যায়। TypeScript generator-এর অনুকরণ করার মতো pattern প্রচুর। মানুষের কোনো workflow দরকার কি না যাচাই করা founder-এর কাছে এই গতি তাত্ত্বিক portability উদ্বেগের চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে।

Go ও PostgreSQL প্রায়ই এমন পণ্যের জন্য ভালো প্রমাণ দেয় যার ঝুঁকিপূর্ণ অংশ backend behavior। explicit API ও worker শুরুতেই idempotency, locking, rate limit, integration retry ও domain boundary পরীক্ষা করতে পারে। প্রাথমিক user interface দ্রুত নাও আসতে পারে, কিন্তু prototype সবচেয়ে ব্যর্থ হওয়ার সম্ভাবনাময় অংশটিই পরীক্ষা করে।

Supabase দিয়ে শুরু করে পরে rewrite করার জনপ্রিয় পরামর্শটি খুবই হালকা করে বলা হয়। বহু পণ্যের rewrite কখনও লাগে না এবং শুরুতেই validation জরুরি বলে এটি জনপ্রিয়। কিন্তু prototype যখন RLS-এ authorization, trigger-এ workflow, provider claim-এ identity, storage convention-এ file এবং realtime subscription-এ event behavior রাখে, অথচ দল সবই অস্থায়ী বলে, তখন পরামর্শটি ভুল। সেই rewrite-এ সব গুরুত্বপূর্ণ contract একসঙ্গে বদলাতে হয়।

উল্টো পরামর্শটিও দুর্বল: scale আসবে বলে এখনই পরিষ্কার Go service তৈরি করা। পণ্য তার যোগ্য কি না জানার আগেই endpoint plumbing, deployment ও service boundary-তে মূল্যবান সময় খরচ হতে পারে। ব্যবহৃত হয়নি এমন architecture-এর uptime নিখুঁত।

স্ক্রিন নয়, ঝুঁকির prototype করুন। tenant policy কঠিন হলে representative RLS rule তৈরি করে cross-tenant test দিয়ে আক্রমণ করুন। background processing কঠিন হলে duplicate delivery, timeout, cancellation ও restart-এর মধ্যে worker চালান। portability চুক্তিগত হলে database restore করে দ্বিতীয় environment-এ application deploy করুন। nontechnical founder-কে পণ্য রক্ষণাবেক্ষণ করতে হলে generation interface দিয়ে বাস্তব schema ও workflow change করতে বলুন, তারপর তৈরি হওয়া diff দেখুন।

planning mode, snapshot ও rollback generated iteration নিরাপদ করতে পারে, কিন্তু application code আগের snapshot-এ ফেরানো গেলেও database rollback-কে time machine বানায় না। customer data মুছে বা বদলে দেয় এমন schema change-এর জন্য backup ও forward recovery plan লাগে।

launch-এর পরের system-এর জন্য সিদ্ধান্তের matrix

পণ্যের কঠিন অংশ custom server behavior হলে, দল Go চালাতে পারলে, SQL control গুরুত্বপূর্ণ হলে এবং বদলানো যায় এমন contract-সহ deployment component চাইলে PostgreSQL-সহ Go নিন। পণ্য মূলত authenticated data workflow হলে, দল TypeScript-এ দক্ষ হলে, integrated service সত্যিকার সেটআপ কমালে এবং RLS পরিষ্কারভাবে permission প্রকাশ করতে পারলে Supabase-সহ Node.js নিন।

বাস্তব পণ্যকে এই মানদণ্ডে এক থেকে পাঁচ নম্বর দিন, তারপর দলের সদস্যদের নম্বরে একের বেশি পার্থক্য থাকলে প্রতিটি নিয়ে আলোচনা করুন:

কলাম দুটির মোট অন্ধভাবে করবেন না। পণ্য নষ্ট করে দিতে পারে এমন দুই বা তিনটি মানদণ্ডকে বেশি ওজন দিন। স্বাস্থ্যসেবার workflow-এ development speed-এর চেয়ে data location ও authorization বেশি গুরুত্বপূর্ণ হতে পারে। অভ্যন্তরীণ approval tool-এ delivery speed ও পরিচিত TypeScript অনেক বেশি গুরুত্বপূর্ণ হতে পারে। data import product worker recovery ও query control-এর ওপর টিকে থাকতে বা হারতে পারে।

সীমানা স্পষ্ট থাকলে hybrid design-ও বৈধ। Go worker Supabase PostgreSQL-এর বিরুদ্ধে দীর্ঘস্থায়ী job process করতে পারে, আর TypeScript web application Auth ও সাধারণ table API ব্যবহার করতে পারে। Node frontend service এমন Go API call করতে পারে যা transactional workflow-এর মালিক। একই state-এ এক invariant owner ছাড়া দুই দিক থেকে পরিবর্তন করা গেলে hybrid ক্ষতিকর হয়।

generation-এর আগে এক পাতার architecture record লিখুন। workload, প্রতিটি invariant-এর কর্তৃপক্ষ, transaction boundary, asynchronous job model, identity source, file ownership, deployment target, recovery method ও portability constraint লিখুন। এরপর generated code-কে সেই পছন্দগুলোর প্রমাণ দিতে বলুন। prompt-এর মান সাহায্য করে, কিন্তু architecture record generator-কে সবচেয়ে বেশি দেখা উদাহরণ অনুযায়ী নীরবে কঠিন সিদ্ধান্ত নেওয়া থেকে আটকায়।

স্ট্যাকের সিদ্ধান্ত সম্পূর্ণ হয় যখন দল অনুমান ছাড়া ব্যর্থ request ব্যাখ্যা করতে, customer state restore করতে এবং business rule কোথায় আছে না খুঁজেই বদলাতে পারে। যে নকশায় এই তিন কাজ স্বাভাবিক হয়, সেটিই নিন।