প্রোডাকশন React ও Flutter প্ল্যাটফর্মের তুলনা

Lovable, Bolt, Replit ও FlutterFlow-এর মধ্যে কোনো একটি পণ্য একই সঙ্গে প্রচলিত প্রোডাকশন React আউটপুট এবং প্রথম শ্রেণির নেটিভ Flutter প্রজেক্ট দেয় না। Lovable, Bolt ও Replit মূলত React ও ওয়েব ডেভেলপমেন্টের দিকে ঝোঁকে। FlutterFlow Flutter তৈরি করে। ডেমোর মানের চেয়ে এই সীমারেখাই বেশি গুরুত্বপূর্ণ।

আপনার রিলিজ পরিকল্পনায় যদি একটি React ওয়েব অ্যাপ্লিকেশন ও একটি নেটিভ Flutter মোবাইল অ্যাপ্লিকেশন লাগে, তাহলে আপনার সামনে দুটি যুক্তিসঙ্গত পথ আছে: শেয়ার করা ব্যাকএন্ড কন্ট্র্যাক্টে আলাদা বিল্ডার ব্যবহার করুন, অথবা এমন একটি প্ল্যাটফর্ম বেছে নিন যা স্পষ্টভাবে দুই স্ট্যাকই সমর্থন করে। React Native, রেসপনসিভ ওয়েব অ্যাপ বা এক্সপোর্ট করা প্রোটোটাইপকে Flutter-এর সমতুল্য ধরলে প্রথম স্টোর বিল্ড বা নেটিভ প্লাগইন ব্যর্থতার সময় পর্যন্ত বিতর্কটা শুধু পিছিয়ে যায়।

প্রম্পট উইন্ডো বন্ধ হওয়ার পর যা থাকে, আমি টুলগুলোকে তা দিয়ে বিচার করি: এমন একটি রিপোজিটরি যা আরেকজন ইঞ্জিনিয়ার ক্লোন করতে পারেন, এমন একটি ডেটাবেস যা পুনরুদ্ধার করা যায়, এমন টেস্ট যা ঠিক কারণে ব্যর্থ হয়, এবং এমন রিলিজ যা একটি ভেন্ডরের একটি বোতামের ওপর নির্ভর করে না। তৈরি হওয়া স্ক্রিন কাজে লাগে। কিন্তু সেগুলো প্রোডাকশন সিস্টেম নয়।

চারটি প্ল্যাটফর্ম কাজের ভিন্ন ভিন্ন অর্ধেক সমাধান করে

সম্পূর্ণ অ্যাপ্লিকেশন ডেভেলপমেন্টের বিষয়ে দাবি কিছুটা মিললেও পণ্যগুলো স্পষ্টভাবে React-কেন্দ্রিক ওয়েব বিল্ডার এবং একটি Flutter বিল্ডারে ভাগ হয়ে যায়।

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

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

Bolt আরও বিস্তৃত JavaScript ওয়ার্কবেঞ্চ দেয়। আপনি কোন ফ্রেমওয়ার্ক, প্যাকেজ ও সার্ভিস সীমারেখা চান তা জানলে এই স্বাধীনতা কাজে আসে। অভিজ্ঞতাহীন একটি দলকেও এটি পরস্পরবিরোধী একাধিক প্যাটার্নের অগোছালো প্রজেক্ট বানাতে দেয়। খারাপ আর্কিটেকচার হলেও এজেন্ট আশ্চর্যজনকভাবে ভালোভাবেই নির্দেশ মানবে।

চারটির মধ্যে Replit-এর সাধারণ প্রোগ্রামিংয়ের ক্ষেত্র সবচেয়ে বিস্তৃত। একটি ওয়ার্কস্পেসেই ফ্রন্টএন্ড ও ব্যাকএন্ড কাজ হোস্ট করতে পারে এবং একটিমাত্র UI ফ্রেমওয়ার্কের সঙ্গে কম বাঁধা। কাস্টম সার্ভার, ওয়ার্কার, নির্ধারিত কাজ বা অস্বাভাবিক ডিপেন্ডেন্সি থাকা অ্যাপ্লিকেশনে এই বিস্তৃতি আকর্ষণীয়, কিন্তু এটি নিজে থেকে পরিপাটি Flutter রিলিজ পাইপলাইন তৈরি করে না।

FlutterFlow এই বিভাজনের অন্য দিক থেকে শুরু করে। এটি Flutter প্রজেক্ট তৈরি করে এবং Flutter উইজেট, অ্যাকশন, স্টেট ও ইন্টিগ্রেশন ঘিরে একটি ভিজ্যুয়াল অ্যাপ্লিকেশন মডেল দেয়। React সোর্স যদি চুক্তিভিত্তিক ডেলিভারেবল হয়, তাহলে ব্রাউজারে এর ওয়েব বিল্ড ঠিকঠাক দেখালেও FlutterFlow সেই শর্ত পূরণ করে না।

React আউটপুটকে বিল্ডারের বাইরেও টিকে থাকতে হবে

প্রোডাকশন React প্রজেক্ট হলো এমন প্রজেক্ট, যা জেনারেশন সার্ভিসকে বাদ দিয়েও সাধারণ রিপোজিটরি টুলিং দিয়ে বিল্ড ও চালানো যায়। ব্রাউজার প্রিভিউ শুধু দেখায় যে বর্তমান হোস্টেড ওয়ার্কস্পেস একবার রেন্ডার হয়েছে। এটি পুনরুৎপাদনযোগ্যতা, ডিপেন্ডেন্সির অখণ্ডতা বা মালিকানা প্রমাণ করে না।

Lovable-এর ক্ষেত্রে দেখুন, এক্সপোর্ট করা রিপোজিটরিতে বোঝার মতো React কম্পোনেন্ট, TypeScript টাইপ, রাউট সংজ্ঞা, এনভায়রনমেন্ট ভ্যারিয়েবল ব্যবস্থাপনা, ডেটাবেস ইন্টিগ্রেশন কোড এবং স্বাভাবিক প্যাকেজ ম্যানিফেস্ট আছে কি না। পরিচিত Vite-ধাঁচের আউটপুট অন্য জায়গায় হোস্ট করা সহজ হতে পারে, কিন্তু তৈরি হওয়া কম্পোনেন্টে প্রায়ই অতিরিক্ত স্টেট, একই ডেটা বারবার আনা এবং প্রেজেন্টেশন লজিক জমতে থাকে। রিপোজিটরিটি সাধারণ React থাকলে এই ত্রুটিগুলো মেরামত করা যায়।

Bolt-ও একই রকম যাচাই দাবি করে, তবে প্রম্পট কী বেছে নিয়েছে সে বিষয়ে বাড়তি নজর দিন। সাধারণভাবে React অ্যাপ বলা একটি প্রজেক্ট Vite, Next.js, Expo পথ বা অন্য কোনো JavaScript বিন্যাস ব্যবহার করতে পারে। প্রতিটির রেন্ডারিং মডেল ও ডিপ্লয়মেন্টের প্রয়োজন আলাদা। কথোপকথনের ট্রান্সক্রিপ্টের ওপর ভরসা না করে নির্বাচিত ফ্রেমওয়ার্কটি রিপোজিটরিতে নথিবদ্ধ করুন।

Replit React ফ্রন্টএন্ডের পাশাপাশি Node, Python, Go বা অন্য সার্ভার তৈরি করতে পারে। এটি ভালো আর্কিটেকচার হতে পারে, তবে তখনই যখন রিপোজিটরি বলে দেয় অংশগুলো কীভাবে শুরু হয়, একে অন্যের সঙ্গে কথা বলে এবং ডিপ্লয় হয়। ওয়ার্কস্পেস-নির্দিষ্ট অটোমেশন দিয়ে সবকিছু চালানো ডেভেলপমেন্ট কমান্ডে প্রোডাকশনের প্রয়োজনীয় স্ক্রিপ্ট অনুপস্থিত থাকার বিষয়টি লুকিয়ে যেতে পারে।

পরিষ্কার চেকআউটে এক্সপোর্ট করা ওয়েব রিপোজিটরি চালান:

npm ci
npm test -- --run
npm run build

সঠিক টেস্ট ফ্ল্যাগ টেস্ট রানারভেদে বদলায়, তাই না বুঝে কপি করার আগে package.json দেখুন। যে প্রমাণ চাইছেন তার চেনা একটি ধরন আছে: লকফাইল থেকে ডিপেন্ডেন্সি ইনস্টল শেষ হয়, কোনো অ্যাসারশন ভাঙলে টেস্ট কমান্ড শূন্য নয় এমন স্ট্যাটাস ফেরায়, এবং বিল্ডারকে যোগাযোগ না করেই বিল্ড নথিবদ্ধ আউটপুট ডিরেক্টরি তৈরি করে।

React-এর নিজস্ব ডকুমেন্টেশন এখন নতুন অ্যাপ্লিকেশনকে এমন ফ্রেমওয়ার্কের দিকে নির্দেশ করে, যখন প্রজেক্টে রাউটিং, ডেটা লোডিং, রেন্ডারিং কৌশল ও প্রোডাকশন রীতি দরকার হয়। পরামর্শটি যুক্তিসঙ্গত, তবে তার মানে এই নয় যে প্রতিটি অভ্যন্তরীণ ড্যাশবোর্ডে বড় ফ্রেমওয়ার্ক লাগবে। সার্ভার আচরণের মালিক আলাদা API হলে সাধারণ React ও Vite অ্যাপ্লিকেশনই আরও পরিষ্কার প্রোডাকশন পছন্দ হতে পারে। বিল্ডারকে সিদ্ধান্তটি স্পষ্টভাবে নিতে বলুন।

নেটিভ Flutter একটি কঠোর প্রযুক্তিগত সীমারেখা

তুলনা করা চারটি পণ্যের মধ্যে শুধু FlutterFlow প্রথম শ্রেণির নেটিভ Flutter প্রজেক্ট দেয়। বাকি তিনটি রেসপনসিভ ওয়েব পেজ, প্রগ্রেসিভ ওয়েব অ্যাপ্লিকেশন বা React Native ও Expo ওয়ার্কফ্লো দিয়ে মোবাইল অভিজ্ঞতা তৈরি করতে পারে, কিন্তু কোনোটির আউটপুটই Flutter নয়।

এই পার্থক্য প্রোগ্রামিং ভাষা, প্যাকেজ ইকোসিস্টেম, রেন্ডারিং আচরণ, নেটিভ প্রজেক্ট ফাইল, টেস্ট টুল এবং প্রয়োজনীয় ইঞ্জিনিয়ারকে প্রভাবিত করে। Flutter Dart ব্যবহার করে এবং Android ও iOS বিল্ড ডিরেক্টরিসহ প্রজেক্ট তৈরি করে। React Native JavaScript বা TypeScript-সহ React-এর কম্পোনেন্ট মডেল ব্যবহার করে। একটি ওয়েব র‍্যাপার নেটিভ শেলের ভেতরে ব্রাউজার কনটেন্ট রাখে। এগুলো আলাদা ডেলিভারি পছন্দ, বিনিময়যোগ্য এক্সপোর্ট ফরম্যাট নয়।

Expo-এর ডকুমেন্টেশন Expo-কে React Native অ্যাপ্লিকেশনের ফ্রেমওয়ার্ক হিসেবে বর্ণনা করে। Flutter-এর ডকুমেন্টেশন Flutter-কে Dart, Flutter উইজেট ও প্ল্যাটফর্ম ইন্টিগ্রেশনকেন্দ্রিক মাল্টিপ্ল্যাটফর্ম ফ্রেমওয়ার্ক হিসেবে বর্ণনা করে। কোনো ভেন্ডর যদি Expo দিয়ে মোবাইল সমর্থনের কথা বলে, কথাটি সঠিক হতে পারে, তবু Flutter-এর শর্ত পূরণ নাও করতে পারে।

বৈধ Flutter এক্সপোর্ট সার্ভিসের বাইরে স্বাভাবিক টুলচেইনে পাস করবে:

flutter pub get
flutter analyze
flutter test
flutter build apk

iOS বিল্ড মেশিনে iOS বিল্ড ও সাইনিং যাচাইও যোগ করুন। বিকল্প হিসেবে ডিভাইস প্রিভিউয়ের স্ক্রিনশট গ্রহণ করবেন না। রিপোজিটরিতে প্রত্যাশিত Dart সোর্স, অ্যাসেট ঘোষণা, প্যাকেজ লক তথ্য, Android কনফিগারেশন, iOS প্রজেক্ট ফাইল এবং প্রয়োজনীয় নেটিভ প্লাগইন সেটআপ থাকতে হবে।

FlutterFlow এই কাঠামো এক্সপোর্ট করতে পারে, কিন্তু তৈরি Flutter কোড সবসময় ব্যবহার করতে সুখকর হয় না। অস্বাভাবিক বড় উইজেট ফাইল, পুনরাবৃত্ত অ্যাকশন, ইঙ্গিতনির্ভর স্টেট পরিবর্তন, তৈরি নাম, কাস্টম কোডের সীমা, ডিপেন্ডেন্সি সংস্করণ ও নেভিগেশন নিয়ম পরীক্ষা করুন। ছোট ভিজ্যুয়াল পরিবর্তনেও কোডের বড় অংশ নতুন করে তৈরি হতে পারে, তাই ওভাররাইট না হয়ে ম্যানুয়াল পরিবর্তন কোথায় থাকবে তা ঠিক করুন।

দলগুলো কখনও কখনও শুধু একটি কোডবেস দাবি করার জন্য ওয়েব অ্যাপটিও Flutter-এ তৈরির প্রস্তাব দেয়। স্থাপত্যের চিত্রটি পরিপাটি দেখায় বলে সুপারিশটি জনপ্রিয়। কিন্তু ওয়েব পণ্য React প্যাকেজ, সার্ভার রেন্ডারিং, ব্রাউজার আচরণের সূক্ষ্ম নিয়ন্ত্রণ বা React দক্ষ কর্মীভিত্তির ওপর নির্ভর করলে এটি ভুল পছন্দ। শেয়ার করা কোড যতটা কাজ কমায়, তার চেয়ে বেশি কাজ তৈরি করা চলবে না।

দুই ক্লায়েন্ট সামঞ্জস্যপূর্ণ থাকবে কি না, তা ব্যাকএন্ড ঠিক করে

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

Lovable প্রায়ই Supabase বা তার ম্যানেজড ক্লাউড পথের সঙ্গে স্বাভাবিকভাবে মানিয়ে যায়। এই জুটি অল্প সেটআপে PostgreSQL ডেটা, প্রমাণীকরণ, স্টোরেজ ও ফাংশন সামলাতে পারে। তৈরি হওয়া প্রতিটি row access policy পরীক্ষা করুন। কোনো ক্লায়েন্ট যদি শুধু অ্যাডমিন বোতাম লুকায়, কিন্তু ডেটাবেসে একই নিয়ম কার্যকর না করে, তাহলে অনুমোদন বাস্তবায়ন হয়নি।

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

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

FlutterFlow Firebase, Supabase ও HTTP API-এর সঙ্গে স্বচ্ছন্দে কাজ করে। শুরুতে সরাসরি ক্লায়েন্ট ইন্টিগ্রেশন দ্রুত ফল দেয়, কিন্তু প্রোডাকশনের অনুমতির নিয়ম সার্ভিসের দিকেই থাকতে হবে। React ও Flutter উভয় ক্লায়েন্ট একই রেকর্ডে লিখলে ভ্যালিডেশন কেন্দ্রীভূত করুন, নইলে প্রয়োজনীয় ফিল্ড, টাইমস্ট্যাম্প, স্ট্যাটাস পরিবর্তন ও ত্রুটি ব্যবস্থাপনা নিয়ে তাদের মতভেদ হবে।

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

দুটি তৈরি ক্লায়েন্ট একটি ব্যাকএন্ড ভাগ করলে OpenAPI-এর মতো API স্কিমা ব্যবহার করুন। স্কিমাটি কমিট করুন, সেখান থেকে ক্লায়েন্ট টাইপ তৈরি বা যাচাই করুন এবং কন্টিনিউয়াস ইন্টিগ্রেশনে অসামঞ্জস্যপূর্ণ পরিবর্তন বাতিল করুন। ছোট একটি কন্ট্র্যাক্ট সাধারণ একটি ব্যর্থতা ঠেকায়: ওয়েব এজেন্ট customer_id বদলে customerId করে, মোবাইল প্রজেক্ট পুরোনো ফিল্ড রাখে, আর দুই প্রিভিউ আলাদা seed data ব্যবহার করে বলে দুটিই সুস্থ দেখায়।

তৈরি টেস্ট সঠিকভাবে ব্যর্থ না হওয়া পর্যন্ত সেগুলো শুধু পরামর্শ

টেস্ট সহায়তা তখনই গুরুত্বপূর্ণ, যখন টেস্ট স্বাধীনভাবে চলে, ইচ্ছাকৃত ত্রুটি শনাক্ত করে এবং রিলিজ আটকে দেয়। কোনো এজেন্টের টেস্ট পাসের রিপোর্ট স্বাধীন প্রমাণ নয়, কারণ একই এজেন্ট দুর্বল অ্যাসারশন লিখতে পারে, কমান্ড এড়িয়ে যেতে পারে, অথবা এমন mock করা পথ পরীক্ষা করতে পারে যা প্রোডাকশন কখনও ব্যবহার করে না।

প্রম্পট দিলে Lovable ও Bolt তাদের রিপোজিটরিতে JavaScript টেস্ট তৈরি করতে পারে। নির্দিষ্ট UI আচরণে কম্পোনেন্ট টেস্ট এবং অর্থ, অনুমতি বা অপরিবর্তনীয় কাজ জড়িত এমন অল্প কয়েকটি প্রবাহে ব্রাউজার টেস্ট চাইুন। তারপর অ্যাসারশন পড়ুন। কোনো পেজে যেকোনো একটি বোতাম আছে কি না দেখা টেস্ট, চেকআউট বোতাম কাজ না করলেও পাস করে যাবে।

Replit তার ওয়ার্কস্পেসে টেস্ট কমান্ড চালাতে পারে এবং বিভিন্ন ভাষার টেস্ট টুল সমর্থন করতে পারে। মিশ্র ফ্রন্টএন্ড ও ব্যাকএন্ড রিপোজিটরির জন্য এটি উপকারী। npm স্ক্রিপ্ট, Make টার্গেট বা টাস্ক ফাইলের মতো সোর্স কন্ট্রোলে নির্ভরযোগ্য কমান্ড রাখুন, যেন অন্য পরিবেশেও একই স্যুট চালানো যায়।

এক্সপোর্টের পর FlutterFlow প্রজেক্টকে flutter analyze ও flutter test চালাতে হবে। নেভিগেশন, সংরক্ষিত স্টেট, অফলাইন পুনরুদ্ধার এবং নেটিভ কোডে যাওয়া প্লাগইনের জন্য ইন্টিগ্রেশন কভারেজ যোগ করুন। উইজেট প্রিভিউ সাইনিং, অনুমতি, ক্যামেরা অ্যাকসেস, নোটিফিকেশন, ব্যাকগ্রাউন্ড কাজ বা অপারেটিং সিস্টেমের লাইফসাইকেল পরিবর্তন যাচাই করে না।

ভালো বহনযোগ্যতা যাচাইয়ে একটি নিয়ন্ত্রিত ব্যর্থতা তৈরি করা হয়। টেস্টে প্রত্যাশিত HTTP স্ট্যাটাস বদলান, কমান্ড ব্যর্থ অবস্থায় বের হয় কি না নিশ্চিত করুন, তারপর আগের অবস্থায় ফিরিয়ে পরিষ্কার রান নিশ্চিত করুন। এই ছোট কাজটি খালি স্যুট, উপেক্ষা করা exit code, ভুল ডিরেক্টরি ও ফল যাই হোক সফলতার বার্তা ছাপানো স্ক্রিপ্ট ধরে ফেলে।

টেস্ট ডেটাকে প্রোডাকশন ডেটা থেকে আলাদা রাখুন। তৈরি অ্যাপ্লিকেশন প্রায়ই একটি সুবিধাজনক প্রজেক্ট, bucket বা ডেটাবেস দিয়ে শুরু হয়। স্বয়ংক্রিয় টেস্ট যখন রেকর্ড মুছে দেয় বা আবার নোটিফিকেশন পাঠায়, তখন সেই সুবিধাই ঘটনায় পরিণত হয়। টেস্ট পরিবেশকে নিজস্ব ক্রেডেনশিয়াল ও এমন ধ্বংসাত্মক অনুমতি দিন যা প্রোডাকশনে পৌঁছাতে পারে না।

শুধু কভারেজের শতকরা হার খারাপ টেস্ট স্যুটকে বাঁচাবে না। প্রমাণীকরণ, বিলিং স্টেট, অনুমতির সীমা ও ডেটা মাইগ্রেশন ঘিরে বোঝার মতো বারোটি টেস্ট, কেউ বোঝে না এমন শত শত স্ন্যাপশটের চেয়ে ভালো। প্রতিটি টেস্ট কোন ব্যর্থতা ঠেকায় তা জিজ্ঞেস করুন। বিশ্বাসযোগ্য উত্তর নেই এমন টেস্ট মুছে ফেলুন বা নতুন করে লিখুন।

ডিপ্লয়মেন্ট বোতাম ভিন্ন দায়িত্ব আড়াল করে

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

Lovable ও Bolt তৈরি হওয়া ওয়েব প্রজেক্ট থেকে হোস্টেড URL-এ যাওয়ার ছোট পথ দেয়। রিভিউ পরিবেশের জন্য এটি চমৎকার এবং সার্ভিস আপনার অ্যাপের প্রয়োজনীয় ডোমেইন, লগ, কনফিগারেশন, আঞ্চলিক আচরণ ও রোলব্যাক নিয়ন্ত্রণ দিলে প্রোডাকশনের জন্যও যথেষ্ট হতে পারে। প্রিভিউ আচরণ থেকে অনুমান না করে ডিপ্লয় করা পরিবেশে প্রতিটি বিষয় যাচাই করুন।

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

FlutterFlow ডিপ্লয়মেন্টকে ওয়েব পাবলিশিং ও নেটিভ অ্যাপ্লিকেশন ডেলিভারিতে ভাগ করে। ওয়েব পাবলিশ দ্রুত হতে পারে। মোবাইল রিলিজে এখনও অ্যাপ্লিকেশন আইডেন্টিফায়ার, সার্টিফিকেট, প্রভিশনিং, স্টোর রেকর্ড, গোপনীয়তা ঘোষণা, স্ক্রিনশট, রিভিউ এবং সংস্করণ ব্যবস্থাপনা লাগে। অপারেটিং সিস্টেম ভেন্ডর ও অ্যাপ স্টোর নিয়ন্ত্রিত অংশ কোনো বিল্ডার বাদ দিতে পারে না।

সম্ভব হলে ডিপ্লয়মেন্টের সংজ্ঞা সোর্সের কাছেই রাখুন। একটি বাহ্যিক হোস্ট লকফাইল থেকে React রিপোজিটরি বিল্ড করতে পারবে। একজন মোবাইল ইঞ্জিনিয়ার নথিবদ্ধ সাইনিং ইনপুট দিয়ে Flutter রিপোজিটরি বিল্ড করতে পারবেন। রিলিজের রেসিপি যদি শুধু বিল্ডার জানে, তাহলে সোর্স এক্সপোর্টে উপকরণ রক্ষা পেলেও রান্নার নির্দেশ হারিয়ে গেছে।

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

সোর্স মালিকানার জন্য বের হওয়ার মহড়া দরকার

অন্য একটি দল মূল অ্যাকাউন্টে প্রবেশাধিকার ছাড়াই যদি সোর্স বিল্ড, ডিপ্লয় ও পরিচালনা করতে পারে, তবেই আপনার উপযোগী সোর্সের মালিকানা আছে। ডাউনলোড বোতাম ফাইলের দখল দেয়, পরিচালনার স্বাধীনতা নয়।

অ্যাপ্লিকেশন সোর্স, অ্যাসেট, ডিপেন্ডেন্সি ম্যানিফেস্ট, লকফাইল, ডেটাবেস মাইগ্রেশন, বিল্ড সেটিং, এনভায়রনমেন্ট ভ্যারিয়েবলের নাম, টেস্ট কমান্ড, লাইসেন্স এবং ডিপ্লয়মেন্ট নির্দেশনার জন্য এক্সপোর্ট পরীক্ষা করুন। Flutter-এর জন্য Android ও iOS প্রজেক্ট কনফিগারেশন যোগ করুন। সার্ভারের জন্য ওয়ার্কার সংজ্ঞা, নির্ধারিত কাজ, স্টোরেজের অনুমান এবং হেলথ এন্ডপয়েন্ট যোগ করুন।

GitHub সিঙ্ক্রোনাইজেশন মনোযোগ দিয়ে পরীক্ষা করা দরকার। এটি একমুখী নাকি দ্বিমুখী, সার্ভিস কোন ব্রাঞ্চে লেখে, ম্যানুয়াল কমিট পুনর্জেনারেশনে টিকে থাকে কি না এবং কমিটের লেখক ও ইতিহাস বোধগম্য থাকে কি না নিশ্চিত করুন। বিল্ডারের বাইরে ছোট একটি পরিবর্তন করে দেখুন, এজেন্ট একই ফাইল সম্পাদনা করলে কী হয়।

তারপর একবার নম্বর দেওয়া exit drill চালান:

1. যে অ্যাকাউন্ট কখনও বিল্ডার খোলেনি, সেখানে রিপোজিটরি এক্সপোর্ট বা ক্লোন করুন।
2. খালি একটি ডেটাবেস প্রস্তুত করুন এবং সোর্স থেকে মাইগ্রেশন প্রয়োগ করুন।
3. নথিবদ্ধ কমান্ডে ওয়েব বা মোবাইল প্রজেক্ট বিল্ড ও টেস্ট করুন।
4. অস্থায়ী ডোমেইন বা অ্যাপ্লিকেশন আইডেন্টিফায়ারের অধীনে ডিপ্লয় করুন।
5. মূল ক্রেডেনশিয়াল রোটেট করুন এবং স্বাধীন ডিপ্লয়মেন্টটি এখনও কাজ করে কি না নিশ্চিত করুন।

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

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

সোর্স অ্যাকসেসকে ডেটা বহনযোগ্যতার সঙ্গে গুলিয়ে ফেলবেন না। ডেটাবেস রেকর্ড, অবজেক্ট স্টোরেজ, স্থানান্তর অনুমোদিত হলে প্রমাণীকরণ পরিচয়, ডোমেইন কনফিগারেশন, অডিট রেকর্ড ও অ্যাপ্লিকেশন সিক্রেটের এক্সপোর্টও দরকার। সবচেয়ে কষ্টের লক সাধারণত React কম্পোনেন্টে নয়, স্টেট ও অপারেশনে থাকে।

ব্যর্থতার পথেই প্রোডাকশন প্রস্তুতি দেখা যায়

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

React ওয়েবে, Flutter মোবাইলে এবং একটি PostgreSQL ব্যাকএন্ডে থাকা বুকিং অ্যাপ্লিকেশনের কথা ভাবুন। দুই ক্লায়েন্টই একটি রিজার্ভেশন পাঠায়। ধীর নেটওয়ার্কে মোবাইল ব্যবহারকারী দুইবার ট্যাপ করেন। প্রথম অনুরোধ কমিট হয়, কিন্তু উত্তরটি হারিয়ে যায়। সফল বুকিংয়ের খবর ক্লায়েন্ট পাওয়ার আগেই পুনরায় চেষ্টা দ্বিতীয় সার্ভার ইনস্ট্যান্সে পৌঁছায়।

এজেন্ট যদি শুধু একটি POST /bookings হ্যান্ডলার তৈরি করে, তাহলে ডেটাবেস দুটি রিজার্ভেশন তৈরি করতে এবং দুবার চার্জ করতে পারে। Flutter-এ বোতাম নিষ্ক্রিয় করা অপারেটিং সিস্টেম, প্রক্সি বা অধৈর্য ব্যবহারকারীর স্ক্রিন আবার খোলা থেকে আসা পুনরায় চেষ্টার সমাধান নয়। ব্যাকএন্ডে একটি idempotency মান, অপারেশনের সঙ্গে যুক্ত uniqueness নিয়ম এবং একই অনুরোধ আবার এলে মূল ফল ফেরত দেওয়ার ব্যবস্থা দরকার।

এবার একটি পুরোনো মোবাইল রিলিজ যোগ করুন। ব্যাকএন্ড নতুন React ক্লায়েন্ট সবসময় পাঠায় এমন একটি আবশ্যক ফিল্ড যোগ করে, কিন্তু ইনস্টল থাকা Flutter সংস্করণ সেটির অস্তিত্বই জানে না। কঠোর, ভার্সনহীন এন্ডপয়েন্ট মোবাইল বুকিং বাতিল করতে শুরু করে। প্রোডাকশন নকশায় মাইগ্রেশন সময়জুড়ে ফিল্ডটি ঐচ্ছিক রাখা হয়, সার্ভার ডিফল্ট দেওয়া হয়, অথবা সামঞ্জস্যপূর্ণ API সংস্করণ আনা হয়।

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

এগুলো দুর্লভ প্রান্তিক ঘটনা নয়। দুটি ক্লায়েন্ট রানটাইম ও একটি বিতরণকৃত ব্যাকএন্ড থাকার সরাসরি ফল। API কন্ট্র্যাক্টে পুনঃচেষ্টার নিয়ম, সামঞ্জস্য নীতি, idempotency আচরণ ও ত্রুটি কোড রাখুন। চালুর আগে দুই ক্লায়েন্ট থেকেই এগুলো পরীক্ষা করুন।

নিরাপত্তা পর্যালোচনা একই কাজের অংশ। প্রতিটি সার্ভিস সীমা, তৈরি হওয়া ডেটাবেস policy, ফাইল আপলোড ভ্যালিডেশন, rate limit, প্রশাসনিক কাজ ও লগ রিড্যাকশনে অনুমোদন পরীক্ষা করুন। React বা Flutter কোডে কখনও বিশেষাধিকারপ্রাপ্ত ডেটাবেস ক্রেডেনশিয়াল পাঠাবেন না। ব্রাউজার বা মোবাইল ডিভাইসে পৌঁছে দেওয়া যেকোনো কিছুকে ব্যবহারকারী দেখতে পারেন ধরে নিন।

ডেলিভারির বিন্যাস অনুযায়ী বেছে নিন

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

মূল ডেলিভারেবল যদি প্রচলিত React ওয়েব অ্যাপ্লিকেশন হয়, গতি গুরুত্বপূর্ণ হয় এবং এর নির্দিষ্ট প্রজেক্ট কাঠামো দলের সঙ্গে মানায়, তাহলে Lovable বেছে নিন। সমর্থিত ম্যানেজড ব্যাকএন্ড ব্যবহার করতে পারে এমন ড্যাশবোর্ড, পোর্টাল ও ডেটাবেস-সমর্থিত পণ্যের জন্য এটি বিশেষভাবে যুক্তিসঙ্গত। কম্পোনেন্ট সীমারেখা পরিষ্কার করা ও অনুমোদন যাচাইয়ের জন্য ইঞ্জিনিয়ারিং সময় বরাদ্দ রাখুন।

আপনি React চান কিন্তু JavaScript প্রজেক্ট ও প্যাকেজে বেশি স্বাধীনতা দরকার হলে Bolt বেছে নিন। এটি এমন ডেভেলপারের জন্য উপযুক্ত, যিনি খারাপ ফ্রেমওয়ার্ক পছন্দ শনাক্ত করতে পারেন, প্যাকেজ পরিবর্তন পরীক্ষা করতে পারেন এবং ক্লায়েন্ট ও সার্ভারের দায়িত্ব কীভাবে ভাগ হবে তা এজেন্টকে স্পষ্ট করে বলতে পারেন। সফল প্রতিটি প্রিভিউ প্রকাশের জন্য প্রস্তুত ধরে নেওয়া প্রতিষ্ঠাতার জন্য এই স্বাধীনতা কম উপকারী।

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

নেটিভ Flutter বাধ্যতামূলক এবং ভিজ্যুয়াল বিল্ডার স্ক্রিন, স্টেট ও ইন্টিগ্রেশন দ্রুত করবে হলে FlutterFlow বেছে নিন। React আউটপুট এর কাজের বাইরে, সেটি মেনে নিন। কাস্টম Dart কোড আলাদা রাখুন, নিয়মিত এক্সপোর্ট করুন এবং স্টোরে জমা দেওয়ার অনেক আগে Android ও iOS বিল্ড দুটিই চালিয়ে দেখুন।

React ওয়েব ক্লায়েন্ট ও Flutter মোবাইল ক্লায়েন্টের জন্য React-কেন্দ্রিক প্ল্যাটফর্মের সঙ্গে FlutterFlow জোড়া দেওয়া কাজ করতে পারে। ব্যাকএন্ড স্কিমা, OpenAPI কন্ট্র্যাক্ট, প্রমাণীকরণ মডেল ও রিলিজ নীতি হবে শেয়ার করা ভিত্তি। প্রজেক্টের মধ্যে ব্যবসায়িক নিয়ম কপি করে তাকে কোড শেয়ারিং বলবেন না।

খরচের তুলনায় জেনারেশনের পরের কাজও ধরুন: সোর্স এক্সপোর্টের সুবিধা, হোস্ট করা ডেটাবেস ব্যবহার, বিল্ড মিনিট, মোবাইল সাইনিং, পর্যবেক্ষণ ব্যবস্থা, ব্যাকআপ, কাস্টম ডোমেইন, ইঞ্জিনিয়ারের পরিষ্কার-পরিচ্ছন্নতার কাজ এবং মাইগ্রেশন প্রয়াস। কম দামের সাবস্ক্রিপশন ব্যয়বহুল হতে পারে, যদি প্রতিটি তৈরি পরিবর্তনে হাতে মেরামত করতে হয়।

দুই রিপোজিটরিই বাস্তব হলে তবেই একটি প্ল্যাটফর্ম দুই কাজ সামলাতে পারে

React ও Flutter দুটোই সমর্থনের দাবি করা প্ল্যাটফর্ম তখনই বিবেচনার যোগ্য, যখন প্রতিটি স্ট্যাকের জন্য এটি স্বাধীন, প্রচলিত প্রজেক্ট এবং তাদের ভাগাভাগি করার মতো একটি ব্যাকএন্ড তৈরি করে। প্রতিটি প্রযুক্তির পাশে টিক চিহ্ন যথেষ্ট নয়।

Koder.ai React ওয়েব অ্যাপ্লিকেশন, PostgreSQL-সহ Go সার্ভিস এবং Flutter মোবাইল প্রজেক্ট ঘিরে তৈরি, এবং এর উল্লেখ করা প্রোডাকশন নিয়ন্ত্রণের মধ্যে রয়েছে সোর্স এক্সপোর্ট, হোস্টিং, কাস্টম ডোমেইন, স্ন্যাপশট, রোলব্যাক ও প্ল্যানিং মোড। তাই এই চাহিদার জন্য এটি সরাসরি একক প্ল্যাটফর্ম প্রার্থী, তবু একই exit drill প্রযোজ্য।

এটিকে একটি ছোট vertical slice তৈরি করতে বলুন: প্রমাণীকরণ, একটি role-protected অপারেশন, একটি ডেটাবেস মাইগ্রেশন, একটি React স্ক্রিন এবং একটি Flutter স্ক্রিন। সবকিছু এক্সপোর্ট করুন। পরিষ্কার পরিবেশে React বিল্ড, Go টেস্ট, ডেটাবেস মাইগ্রেশন, Flutter analysis ও Flutter test চালান।

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

প্ল্যাটফর্মটি Flutter-এর বদলে React Native বসালে, শুধু ওয়েব র‍্যাপার এক্সপোর্ট করলে, নেটিভ প্রজেক্ট ফাইল বাদ দিলে বা ব্যাকএন্ড স্কিমা লুকালে তা বাতিল করুন। সতর্কতা ছাড়া ম্যানুয়াল সোর্স সম্পাদনা মুছে গেলে বা প্রোডাকশন বিল্ড অনথিবদ্ধ ওয়ার্কস্পেস স্টেটের ওপর নির্ভর করলে তাও বাতিল করুন।

বিজয়ী সেই সার্ভিস নয়, যা প্রথম স্ক্রিনটি সবচেয়ে চমৎকার তৈরি করে। বিজয়ী হলো সেটি, যার আউটপুট মূল চ্যাট অপ্রাসঙ্গিক হয়ে যাওয়ার পরও আপনার দল টেস্ট, রিলিজ, মেরামত ও স্থানান্তর করতে পারে। প্রতিশ্রুতিবদ্ধ হওয়ার আগে নিজের রিপোজিটরি দিয়ে ভেন্ডরকে সেটি প্রমাণ করতে বলুন।