सर्व्हर म्हणजे काय? अॅप बनवणाऱ्यांसाठी सोपे मार्गदर्शक

सर्व्हर हा असा संगणक आहे — किंवा एखाद्या संगणकावर चालणारा प्रोग्राम — जो विनंत्यांची वाट पाहतो आणि त्यांना उत्तर देतो. तुम्ही वेबसाइट उघडता तेव्हा तुमचा ब्राउझर (client) इंटरनेटवरून विनंती पाठवतो, आणि कुठेतरी असलेला सर्व्हर पेज, प्रतिमा किंवा डेटा परत पाठवतो. ईमेलपासून ऑनलाइन बँकिंगपर्यंत तुम्ही वापरता ते प्रत्येक अॅप सर्व्हर दिवसाला लाखो वेळा हे करत असल्यावर अवलंबून असते.

AI सह तयार करताना सर्व्हर का महत्त्वाचे आहेत

जेव्हा AI बिल्डर तुम्हाला अॅप बनवून देतो, तेव्हा त्या कोडचा काही भाग भेट देणाऱ्याच्या ब्राउझरमध्ये चालतो आणि काही भाग सहसा सर्व्हरवर चालतो. सर्व्हरचा भाग त्या गोष्टी करतो ज्या ब्राउझरवर विश्वास ठेवता येत नाही किंवा ज्या ब्राउझर एकट्याने करू शकत नाही:

• डेटा साठवणे आणि लोड करणे डेटाबेस मधून.
• रहस्ये ठेवणे, जसे पेमेंट किंवा AI provider च्या API keys, ज्या कधीही ब्राउझरपर्यंत पोहोचू नयेत.
• परवानग्या तपासणे — वापरकर्ता फक्त स्वतःचे रेकॉर्ड्स पाहू आणि बदलू शकेल याची खात्री करणे.
• इतर सेवांशी बोलणे: कार्डवर शुल्क आकारणे, ईमेल पाठवणे, AI model ला कॉल करणे.

सर्व्हर काय करतो हे माहीत असल्यास तुमच्या अॅपचे नियम खरोखर कुठे राहतात, काही बदलांसाठी पुन्हा publish का करावे लागते, आणि अॅप होस्ट करताना तुम्ही कशासाठी पैसे देत आहात हे समजते. दोन अर्ध्या भागांमधील विभागणीसाठी frontend विरुद्ध backend पहा.

रोजच्या उदाहरणातून

सर्व्हर म्हणजे पोस्ट ऑफिसमधील काउंटरवरील कर्मचारी. ते बाहेर ग्राहक शोधायला जात नाहीत; ते वाट पाहतात. एक ग्राहक (client) विनंती घेऊन येतो — "हे पार्सल पाठवा," "माझ्यासाठी काही पत्र आहे का?" — आणि कर्मचारी ते हाताळून निकाल परत देतो. एक कर्मचारी अनेक ग्राहकांना एकापाठोपाठ सेवा देऊ शकतो, आणि गर्दीच्या पोस्ट ऑफिसमध्ये आणखी काउंटर उघडले जातात.

पोस्ट ऑफिसचेही असे नियम आहेत जे ग्राहक बदलू शकत नाही: पार्सल घेण्यासाठी ओळखपत्र दाखवावे लागते. अॅपमध्येही हेच काम सर्व्हरचे असते — ब्राउझर काहीही मागू शकतो, पण सर्व्हर ठरवतो की त्याला काय मिळेल.

एखादी विनंती सर्व्हरपर्यंत कशी पोहोचते

जेव्हा कोणी https://bookings.example.com/schedule भेट देतो:

1. DNS lookup. ब्राउझर डोमेन नेम सिस्टमला विचारतो की bookings.example.com कोणत्या IP पत्त्याकडे निर्देश करते. पाहा domains आणि DNS कसे काम करतात.
2. Connection. ब्राउझर त्या पत्त्याशी HTTPS साठी port 443 वर जोडतो, आणि एनक्रिप्टेड कनेक्शन सेट करतो. पाहा HTTPS म्हणजे काय.
3. Request. ते HTTP विनंती पाठवते: GET /schedule.
4. Work. सर्व्हर /schedule हाताळणारा कोड चालवतो — कदाचित डेटाबेसमधून आजच्या बुकिंग्स शोधतो.
5. Response. तो एक status code (200 OK) आणि मजकूर परत पाठवतो — HTML पेज, किंवा पेजला दाखवण्यासाठी JSON डेटा.

हे सर्व सहसा सेकंदाच्या अंशात होते.

तुम्हाला ऐकू येणारे सर्व्हरचे प्रकार

लक्षात ठेवा की "सर्व्हर" म्हणजे यंत्र आणि प्रोग्राम दोन्ही. "सर्व्हर क्रॅश झाला" याचा अर्थ दोन्हीपैकी काहीही असू शकतो.

एक उदाहरण: सलून बुकिंग अॅप

एका लहान सलून बुकिंग अॅपमध्ये सर्व्हर हे करतो:

• भेट देणारा साइट उघडतो. सर्व्हर (किंवा त्यासमोरील CDN) पेज फाइल्स पाठवतो.
• पेज सर्व्हरला GET /api/slots?date=2026-10-03 विचारते. सर्व्हर डेटाबेसला मोकळे स्लॉट्स विचारतो आणि ते JSON म्हणून परत करतो.
• भेट देणारा 14:00 बुक करतो. पेज POST /api/bookings पाठवते. सर्व्हर तपासतो की स्लॉट अजूनही मोकळा आहे — तो ब्राउझरच्या शब्दावर विश्वास ठेवत नाही — बुकिंग जतन करतो आणि 201 Created परत करतो.
• सर्व्हर पुष्टीकरण ईमेल पाठवण्यासाठी ईमेल सेवेला गुप्त key वापरून कॉल करतो, जी सर्व्हरवर ठेवलेली असते.

सर्व्हर बंद केला, तर कदाचित पेज CDN वरून लोड होईल, पण स्लॉट्स दाखवता येणार नाहीत किंवा बुकिंग्स जतन होणार नाहीत.

सर्व्हर चांगला चालण्यासाठी काय लागते

• मेमरी (RAM) आणि CPU. मेमरी कमी असेल तर भार पडल्यावर अॅप कोसळते; CPU कमी असेल तर ते संथ होते.
• चालू असणे. बंद असलेला सर्व्हर उत्तर देऊ शकत नाही. काही platforms निष्क्रिय अॅप्स झोपवतात आणि पुढील भेटीवर जागे करतात, ज्यामुळे पैसे वाचतात पण पहिली विनंती थोडी संथ होऊ शकते.
• कॉन्फिगरेशन आणि रहस्ये, एन्व्हायर्नमेंट व्हेरिएबल्स म्हणून दिलेली.
• Logs — सर्व्हरने काय घडले याची नोंद, जी काही तुटल्यावर सर्वात आधी तपासली जाते.
• अपडेट्स आणि सुरक्षा पॅचेस, जे व्यवस्थापित होस्टिंग तुमच्यासाठी करते.

सामान्य गैरसमज

• "क्लाउड म्हणजे सर्व्हर नाहीत." क्लाउड म्हणजे इतर कंपन्यांचे सर्व्हर, तासाने किंवा वापराने भाड्याने घेतलेले.
• "सर्व्हर म्हणजे एक मोठा विशेष संगणक." कोणताही संगणक सर्व्हर म्हणून काम करू शकतो. विकासादरम्यान तुम्ही localhost उघडता तेव्हा तुमचा laptop एक चालवत असतो.
• "बटण लपवले, तर वापरकर्ते ते करू शकत नाहीत." कोणीही थेट तुमच्या सर्व्हरला विनंत्या पाठवू शकतो. परवानगी तपासण्या सर्व्हरवर झाल्या पाहिजेत, फक्त पेजमध्ये नव्हे.
• "अधिक सर्व्हर जोडले की संथपणा जातो." अनेकदा खरे कारण संथ डेटाबेस query किंवा बाहेरचा API असतो. आधी अडथळा शोधा.
• "अॅप असण्यासाठी मला सर्व्हर व्यवस्थापित करावा लागेल." व्यवस्थापित platforms सर्व्हर चालवतात; तुम्ही कोड deploy करता आणि ते यंत्रे हाताळतात.

तुमच्या AI बिल्डरकडे काय विचारावे

• "या अॅपचा कोणता भाग सर्व्हरवर चालतो, आणि कोणता ब्राउझरमध्ये?"
• "सर्व API keys सर्व्हरवर ठेवा आणि त्या एन्व्हायर्नमेंट व्हेरिएबल्समधून वाचा."
• "डेटा वाचणारी किंवा बदलणारी प्रत्येक विनंती सर्व्हरवर परवानग्यांसाठी तपासा."
• "सर्व्हर logs कुठे आहेत, आणि या त्रुटीबद्दल ते काय सांगतात?"
• "हे अॅप खरोखर सर्व्हरची गरज आहे का, की ते स्थिर साइट असू शकते?"
• "अॅप निष्क्रिय राहिल्यानंतर पहिल्या विनंतीचे काय होते?"

Mythex वरील सर्व्हर

Mythex मध्ये तुम्ही सर्व्हर सेट करत नाही किंवा व्यवस्थापित करत नाही. बांधताना तुमचे अॅप लाइव्ह preview साठी एका खाजगी क्लाउड sandbox मध्ये चालते. publish केल्यावर Mythex ते deploy करते: static front ends static sites म्हणून, आणि backends (Node, Python, C#, Java आणि इतर) Dockerfile वरून बनवलेले containers म्हणून — होस्टिंग स्वतः कॉन्फिगर न करता. deploy करताना Mythex मशीनचा आकार ठरवते: डीफॉल्टने 1 CPU आणि 512 MB मेमरी, विनंतीवर अधिक उपलब्ध (Free वर 1 GB पर्यंत, आणि Pro वर 2 CPUs, 4 GB आणि 3 मशीन्सपर्यंत). प्रकाशित अॅप्स निष्क्रिय असताना झोपतात आणि पुढील भेटीवर जागे होतात, आणि झोपलेला अॅप compute वर काहीही खर्च करत नाही. तपशील docs मधील API backends आणि होस्टिंग मर्यादा मध्ये आहेत, आणि आमचे वेब होस्टिंग मार्गदर्शक व्यापक चित्र देते.

प्रश्न