সার্ভার কী? অ্যাপ নির্মাতাদের জন্য সহজ গাইড

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

AI দিয়ে তৈরি করলে সার্ভার কেন গুরুত্বপূর্ণ

AI বিল্ডার আপনার জন্য একটি অ্যাপ বানালে তার কিছু কোড দর্শকের ব্রাউজারে চলে, আর কিছু সাধারণত একটি সার্ভারে চলে। সার্ভারের অংশটি সেসব কাজ করে যা ব্রাউজারকে বিশ্বাস করা যায় না বা একা করা যায় না:

• ডেটা সংরক্ষণ ও লোড করা একটি ডেটাবেস থেকে।
• গোপনীয় কী রাখা, যেমন পেমেন্ট বা AI প্রদানকারীর API কী, যা কখনো ব্রাউজারে পৌঁছানো উচিত নয়।
• অনুমতি যাচাই করা — নিশ্চিত করা যে একজন ব্যবহারকারী শুধু নিজের রেকর্ড দেখতে ও বদলাতে পারে।
• অন্য সার্ভিসের সঙ্গে কথা বলা: কার্ডে চার্জ করা, ইমেইল পাঠানো, AI মডেল ডাকা।

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

একটি দৈনন্দিন উপমা

একটি ডাকঘরের কাউন্টার কর্মীর মতো সার্ভার। তারা নিজে থেকে গ্রাহক খুঁজতে বের হন না; অপেক্ষা করেন। একজন গ্রাহক (ক্লায়েন্ট) একটি অনুরোধ নিয়ে আসেন — “এই পার্সেলটি পাঠাও,” “আমার নামে কোনো চিঠি আছে?” — কর্মী সেটি সামলান এবং একটি ফলাফল ফেরত দেন। একজন কর্মী একের পর এক অনেক গ্রাহকের সেবা দিতে পারেন, আর ব্যস্ত ডাকঘরে আরও কাউন্টার খোলা হয়।

ডাকঘরের কিছু নিয়মও আছে যা গ্রাহক বদলাতে পারেন না: পার্সেল নিতে পরিচয়পত্র দেখাতে হয়। অ্যাপেও সার্ভারের কাজ এটিই — ব্রাউজার যা খুশি চাইতে পারে, কিন্তু কী পাবে তা সার্ভার ঠিক করে।

একটি অনুরোধ কীভাবে সার্ভারে পৌঁছায়

যখন কেউ https://bookings.example.com/schedule খোলেন:

1. DNS লুকআপ। ব্রাউজার ডোমেইন নেম সিস্টেমকে জিজ্ঞেস করে bookings.example.com কোন IP ঠিকানা নির্দেশ করে। দেখুন ডোমেইন ও DNS কীভাবে কাজ করে।
2. সংযোগ। ব্রাউজার সেই ঠিকানায় সংযোগ করে, HTTPS-এর জন্য পোর্ট 443-এ, এবং একটি এনক্রিপ্টেড সংযোগ গড়ে তোলে। দেখুন HTTPS ও SSL কী।
3. অনুরোধ। এটি একটি HTTP অনুরোধ পাঠায়: GET /schedule।
4. কাজ। সার্ভার /schedule সামলানো কোড চালায় — হয়তো ডেটাবেস থেকে আজকের বুকিং খোঁজে।
5. উত্তর। এটি একটি স্ট্যাটাস কোড (200 OK) ও কনটেন্ট পাঠায় — একটি HTML পেজ, অথবা পেজের দেখানোর জন্য JSON ডেটা।

এই সবকিছু সাধারণত এক সেকেন্ডের ভগ্নাংশে ঘটে।

যেসব ধরনের সার্ভারের নাম শুনবেন

লক্ষ করুন “সার্ভার” শব্দটি মেশিন এবং প্রোগ্রাম — দুটো অর্থেই। “সার্ভার ক্র্যাশ করেছে” বললে দুটোর যেকোনোটিই বোঝাতে পারে।

একটি বাস্তব উদাহরণ: একটি সেলুন বুকিং অ্যাপ

ছোট একটি সেলুন বুকিং অ্যাপে সার্ভার যা করে:

• একজন দর্শক সাইট খোলেন। সার্ভার (বা এর সামনের একটি CDN) পেজ ফাইল পাঠায়।
• পেজটি সার্ভারকে জিজ্ঞেস করে GET /api/slots?date=2026-10-03। সার্ভার ডেটাবেসে খালি স্লট কোয়েরি করে এবং JSON হিসেবে ফেরত দেয়।
• দর্শক ১৪:০০ বুক করেন। পেজ POST /api/bookings পাঠায়। সার্ভার যাচাই করে স্লটটি এখনো খালি — ব্রাউজারের কথায় ভরসা করে না — বুকিং সংরক্ষণ করে এবং 201 Created ফেরত দেয়।
• সার্ভার একটি ইমেইল সার্ভিসকে ডাকে, সার্ভারে রাখা একটি গোপন কী দিয়ে, নিশ্চিতকরণ ইমেইল পাঠাতে।

সার্ভার বন্ধ করে দিলে পেজটি হয়তো তবু CDN থেকে লোড হতো, কিন্তু স্লট দেখাতে বা বুকিং সংরক্ষণ করতে পারত না।

একটি সার্ভারের ভালো চলতে কী লাগে

• মেমরি (RAM) ও CPU। মেমরি কম হলে চাপে অ্যাপ ক্র্যাশ করে; CPU কম হলে ধীর হয়ে যায়।
• চালু থাকা। বন্ধ সার্ভার উত্তর দিতে পারে না। কিছু প্ল্যাটফর্ম অলস অ্যাপকে ঘুম পাড়িয়ে দেয় এবং পরের ভিজিটে জাগায়; এতে খরচ বাঁচে, কিন্তু প্রথম অনুরোধ ধীর হতে পারে।
• কনফিগারেশন ও সিক্রেট, এনভায়রনমেন্ট ভেরিয়েবল হিসেবে দেওয়া।
• লগ — সার্ভারের ঘটনার রেকর্ড, যেখানে কিছু ভাঙলে আগে দেখতে হয়।
• আপডেট ও নিরাপত্তা প্যাচ, যা ম্যানেজড হোস্টিং আপনার হয়ে করে।

সাধারণ ভুল ধারণা

• “ক্লাউড মানেই কোনো সার্ভার নেই।” ক্লাউড হলো অন্যদের সার্ভার, যা ঘণ্টা বা ব্যবহার অনুযায়ী ভাড়া নেওয়া হয়।
• “সার্ভার মানে একটি বড়, বিশেষ কম্পিউটার।” যেকোনো কম্পিউটারই সার্ভারের কাজ করতে পারে। ডেভেলপমেন্টের সময় localhost খুললে আপনার ল্যাপটপই একটি সার্ভার চালায়।
• “বাটন লুকানো থাকলে ব্যবহারকারী কাজটি করতে পারবে না।” যেকোনো কেউ সরাসরি আপনার সার্ভারে অনুরোধ পাঠাতে পারে। অনুমতি যাচাই পেজে নয়, সার্ভারে হতে হবে।
• “বেশি সার্ভার মানেই ধীরগতির সমাধান।” প্রায়ই আসল কারণ একটি ধীর ডেটাবেস কোয়েরি বা একটি বাইরের API। আগে বাধা খুঁজে বের করুন।
• “অ্যাপ থাকার জন্য আমাকে সার্ভার পরিচালনা করতে হবে।” ম্যানেজড প্ল্যাটফর্ম সার্ভার চালায়; আপনি কোড ডিপ্লয় করেন এবং তারা মেশিনগুলো সামলায়।

আপনার AI বিল্ডারকে কী জিজ্ঞেস করবেন

• “এই অ্যাপের কোন অংশ সার্ভারে চলে, আর কোনটি ব্রাউজারে চলে?”
• “সব API কী সার্ভারে রাখো এবং এনভায়রনমেন্ট ভেরিয়েবল থেকে পড়ো।”
• “ডেটা পড়ে বা বদলায় এমন প্রতিটি অনুরোধে সার্ভারে অনুমতি যাচাই করো।”
• “সার্ভারের লগ কোথায় পাব, এবং এই ত্রুটি সম্পর্কে সেগুলো কী বলে?”
• “এই অ্যাপের আদৌ কি সার্ভার লাগে, নাকি এটি একটি স্ট্যাটিক সাইট হতে পারে?”
• “অ্যাপ কিছুক্ষণ অলস থাকার পর প্রথম অনুরোধের কী হয়?”

Mythex-এ সার্ভার

Mythex-এ সার্ভার সেটআপ বা পরিচালনা আপনাকে করতে হয় না। বানানোর সময় লাইভ প্রিভিউয়ের জন্য আপনার অ্যাপ একটি ব্যক্তিগত ক্লাউড স্যান্ডবক্সে চলে। প্রকাশ করলে Mythex ডিপ্লয় করে — স্ট্যাটিক ফ্রন্টএন্ড স্ট্যাটিক সাইট হিসেবে, এবং ব্যাকএন্ড (Node, Python, C#, Java ও অন্যান্য) একটি Dockerfile থেকে বানানো কন্টেইনার হিসেবে — নিজে কিছু কনফিগার না করেই। ডিপ্লয়ের সময় মেশিনের আকার Mythex ঠিক করে: ডিফল্টে ১ CPU ও ৫১২ MB মেমরি, অনুরোধে আরও পাওয়া যায় (Free-তে ১ GB পর্যন্ত, আর Pro-তে ২ CPU, ৪ GB ও ৩টি মেশিন পর্যন্ত)। প্রকাশিত অ্যাপ অলস থাকলে ঘুমায় এবং পরের ভিজিটে জাগে; ঘুমন্ত অ্যাপ কম্পিউটের জন্য কিছু খরচ করে না। বিস্তারিত আছে API ব্যাকএন্ড ও হোস্টিং সীমা ডকুমেন্টেশনে, আর বৃহত্তর চিত্রের জন্য আমাদের ওয়েব হোস্টিং গাইডটি।

প্রশ্নোত্তর