Full-Stack ऐप क्या है? एक सरल व्याख्या

Full-stack ऐप वह ऐप है जिसमें काम करने के लिए ज़रूरी हर परत शामिल हो: frontend जिसे लोग देखते और क्लिक करते हैं, backend जो सर्वर पर चलता है और नियम लागू करता है, और database जो सब कुछ याद रखता है। Task list जो आपके कार्य सेव करती है, किसी भी डिवाइस से लॉग-इन करने देती है, और किसी और को आपकी list नहीं दिखाती, वह full-stack है। एक अकेला पेज जो केवल आपके खुलने का समय दिखाता है, वह नहीं है।

"Stack" का मतलब बस तकनीक की परतें हैं जो एक-दूसरे के ऊपर रखी जाती हैं। "Full" का मतलब है कि वे सभी मौजूद हैं।

AI से बनाते समय यह क्यों मायने रखता है

जब आप किसी AI builder को ऐप का विवरण देते हैं, तो आपके शब्द तय करते हैं कि वह कौन सी परतें बनाएगा। "हमारा मेन्यू दिखाने वाला पेज बनाओ" एक frontend बनाता है। "ग्राहक हमारे मेन्यू से order कर सकें और रसोई नए orders देख सके" के लिए तीनों परतें चाहिए, क्योंकि orders सेव होने चाहिए, दो तरह के यूज़र्स के बीच बाँटे जाने चाहिए और निजी रखे जाने चाहिए।

अंतर समझने से तीन फ़ायदे होते हैं:

• आप सही चीज़ माँगते हैं। अगर आपको डेटा सेव चाहिए, तो साफ़ कहें। जो builder केवल frontend बनाता है, वह पूरा दिखेगा पर refresh पर सब कुछ भूल जाएगा।
• नकली पूर्णता पहचानते हैं। Sample डेटा वाला डेमो हूबहू एक काम करते ऐप जैसा दिख सकता है। परतें जानने से आप जाँच सकते हैं कि डेटा सच में कहीं जाता है।
• चलने की लागत समझते हैं। अकेला frontend static फ़ाइलों के रूप में परोसा जा सकता है। Backend और database सर्वर पर चलने वाले प्रोग्राम हैं, और hosting का ज़्यादातर खर्च यहीं से आता है।

रोज़मर्रा की मिसाल: एक रेस्टोरेंट

एक रेस्टोरेंट के बारे में सोचिए।

• डाइनिंग हॉल frontend है। मेन्यू, टेबल और वेटर का नोटपैड। यही मेहमान देखते हैं, और यह सुखद और आसान इस्तेमाल योग्य होना चाहिए।
• रसोई backend है। मेहमान अंदर नहीं जाते। वहाँ ऑर्डर लिए जाते हैं, जाँचा जाता है कि डिश उपलब्ध है या नहीं, वह पकाई जाती है, और अजीब अनुरोध ठुकराए जाते हैं। नियम यहीं रहते हैं।
• पेंट्री और ऑर्डर की किताब database हैं। इनमें रहता है कि क्या मौजूद है और क्या ऑर्डर हुआ है, ताकि शिफ़्ट बदलने पर कुछ न भूले।

सिर्फ़ डाइनिंग हॉल वाला रेस्टोरेंट आपको एक सुंदर मेन्यू दिखा सकता है, पर आपको खाना नहीं मिलेगा। वह एक frontend-only ऐप है जो full-stack होने का दिखावा कर रहा है।

तीनों परतें विस्तार से

ये परतें एक तय क्रम में बात करती हैं। Frontend backend से कुछ माँगता है एक API के ज़रिए — requests का एक परिभाषित सेट जिसे backend स्वीकार करता है। Backend request की जाँच करता है, database को पढ़ता या लिखता है, और जवाब भेजता है। Frontend सीधे database से बात नहीं करता।

वह क्रम पूरे स्टैक का सबसे महत्वपूर्ण सुरक्षा विचार है। Frontend में जो भी है उसे विज़िटर पढ़ और बदल सकता है, क्योंकि वह उसकी डिवाइस पर चलता है। इसलिए नियम — "यह invoice केवल मालिक देख सकता है", "कूपन एक बार ही इस्तेमाल हो सकता है" — backend में लागू होने चाहिए। इस विभाजन के बारे में अधिक जानने के लिए frontend बनाम backend देखें।

एक उदाहरण: एक क्लास बुकिंग ऐप

मान लीजिए आप एक योग स्टूडियो चलाते हैं और चाहते हैं कि लोग क्लासेस ऑनलाइन बुक करें।

विज़िटर क्या करता है: साइट खोलता है, इस हफ़्ते की क्लासेस देखता है, एक को टैप करता है, लॉग-इन करता है और एक जगह बुक करता है।

अंदर क्या होता है:

1. Frontend टाइमटेबल दिखाता है। उसे भरने के लिए वह backend से पूछता है, "इस हफ़्ते कौन सी क्लासेस हैं, और कितनी जगहें बची हैं?"
2. Backend database से क्लासेस माँगता है, हर क्लास की bookings गिनता है, फिर जवाब देता है।
3. विज़िटर Book दबाता है। Frontend भेजता है "इस लॉग-इन व्यक्ति के लिए क्लास 42 बुक करो"।
4. Backend जाँचता है: क्या यह व्यक्ति सच में लॉग-इन है? क्या क्लास भरी है? क्या वे इसे पहले ही बुक कर चुके हैं? केवल सब ठीक होने पर ही वह database में नई booking row लिखता है।
5. Backend "booked" का जवाब देता है, और frontend पुष्टि दिखाता है।
6. बाद में स्टूडियो की मालिक लॉग-इन करती है और क्लास की सूची देखती है। Backend जाँचता है कि वह admin है, फिर ही सबके नाम दिखाता है।

अब सोचिए यह केवल frontend के रूप में बना होता। टाइमटेबल दिख सकता है, और Book बटन एक सुंदर टिक दिखा सकता है, पर refresh पर booking गायब हो जाती, "बची हुई जगहों" की गिनती बाकी सबके लिए गलत होती, और मालिक उसे कभी नहीं देखती। चरण 4 — जाँचें — पूरी तरह गायब होतीं। यही व्यावहारिक फ़र्क है।

मुख्य शब्द

• Frontend (client side): वह हिस्सा जो browser में चलता है।
• Backend (server side): वह हिस्सा जो सर्वर पर चलता है। इसे API सर्वर भी कहते हैं।
• Database: वह जगह जहाँ डेटा व्यवस्थित ढंग से स्टोर होता है। देखें database क्या है।
• API: उन requests की सूची जिन्हें backend frontend या दूसरे प्रोग्रामों से स्वीकार करता है।
• Authentication: जाँचना कि कोई कौन है (लॉग-इन)। Authorisation: जाँचना कि वह क्या कर सकता है।
• Deployment: सभी परतों को सर्वरों पर रखना ताकि जनता उनका इस्तेमाल कर सके।
• Monolith बनाम services: एक प्रोग्राम जो सब कुछ करता है, बनाम कई छोटे प्रोग्राम (जैसे एक वेबसाइट और एक अलग API)। दोनों full-stack हैं।

आम गलतियाँ और गलतफ़हमियाँ

• "दिख रहा है तो हो गया।" Sample डेटा और सही दिखने वाला बटन सेव किए गए डेटा के बराबर नहीं हैं। पेज refresh करें, उसे private window में खोलें, और जाँचें कि डेटा अब भी है।
• नियम frontend में डालना। बटन छिपाना सुरक्षा नहीं है। अगर backend जाँच नहीं करता, तो जो भी request का तरीका जानता है, वह उसे भेज सकता है।
• Secret keys frontend में डालना। Browser कोड में पेमेंट या AI provider की key हर विज़िटर पढ़ सकता है। Keys backend पर, environment variables में होनी चाहिए — देखें environment variables और secrets।
• सोचना कि full-stack का मतलब जटिल है। एक छोटा full-stack ऐप कुछ screens, कुछ backend routes और तीन database tables का हो सकता है। यह परतों का वर्णन है, आकार का नहीं।
• सोचना कि हर तकनीक खुद चुननी होगी। पहले संस्करण के लिए कोई भी समझदार, व्यापक रूप से इस्तेमाल होने वाला stack काम करेगा। डेटा और नियमों का साफ़ विवरण ज़्यादा मायने रखता है।

अपने AI builder से क्या माँगें

ऐप का विवरण तीन परतों के संदर्भ में दें, भले ही आप उन्हें नाम न दें:

• डेटा: "क्लासेस (नाम, समय, क्षमता) और bookings (क्लास, व्यक्ति, बुक करने का समय) को database में सेव करें।"
• नियम: "किसी क्लास में क्षमता से ज़्यादा booking न हो। एक व्यक्ति एक क्लास केवल एक बार बुक कर सकता है। केवल admins देख सकें कि किसने बुक किया।"
• स्क्रीन: "साप्ताहिक टाइमटेबल, booking की पुष्टि, और एक admin page जो हर क्लास की bookings दिखाए।"
• जाँचें: "ये नियम केवल पेज में नहीं, सर्वर पर लागू करें। कोई भी API key सर्वर पर रखें।"

फिर संदेही की तरह टेस्ट करें: refresh करें, दो अलग लोगों के रूप में लॉग-इन करें, वह डेटा देखने की कोशिश करें जो आपको नहीं देखना चाहिए। AI से ऐप बनाने की गाइड इस पूरे चक्र को शुरू से अंत तक समझाती है।

Mythex पर full-stack ऐप्स

Mythex chat में दिए गए विवरण से full-stack web ऐप्स बनाता है। डिफ़ॉल्ट रूप से नए ऐप को React और TypeScript का frontend मिलता है; जब ऐप को डेटा सेव करना होता है, तो Mythex प्रोजेक्ट में एक समर्पित Postgres database जोड़ता है, और आप वेबसाइट के साथ एक अलग API सर्वर (जैसे Python, Node, C# या Java) भी माँग सकते हैं। सब कुछ एक live preview में एक साथ चलता है और एक सार्वजनिक URL पर publish होता है। Multi-service ऐप्स वाला docs पेज दिखाता है कि वेबसाइट और API एक साथ कैसे preview और publish होते हैं, और full-stack ऐप बिल्डर पेज पर शुरुआती बिंदु मिलते हैं।

सवाल