AI से बनी app के अंदर असल में क्या होता है: non-developers के लिए एक टूर

आपने एक description टाइप किया, go दबाया, और बीस मिनट बाद आपके पास एक चलती हुई app थी। बढ़िया। पर अब आपने “view files” पर क्लिक किया है और आप एक folder tree को घूर रहे हैं जो ऐसा लगता है जैसे किसी दूसरी भाषा में लिखा हो। package.json क्या है? node_modules में चालीस चीज़ें क्यों हैं? “schema” का मतलब क्या है और आपके पास एक क्यों है?

यह पोस्ट एक गाइडेड टूर है। tutorial नहीं — एक टूर। इसे पढ़ने के बाद आपको ख़ुद इनमें से कोई file लिखना नहीं आएगा, पर अगली बार जब कुछ अजीब लगेगा, तो आपको पता होगा कि app के किस कोने की ओर इशारा करना है।

मैं पूरे टूर में तीन चलते-फिरते उदाहरण इस्तेमाल करूंगा, ताकि अमूर्त हिस्सों को टिकने के लिए कुछ ठोस मिले:

• Maya, एक marketing lead, जिसने अपनी टीम के लिए एक referral leaderboard बनाया।
• Jordan, एक yoga teacher, जिसने एक class booking site बनाई।
• Sam, जो एक bakery चलाते हैं, जिन्होंने एक “कल के croissants pre-order करें” page बनाया।

तीनों ने एक AI app builder इस्तेमाल किया। तीनों apps किसी customer को बिल्कुल अलग दिखती हैं। पर अंदर से, इनकी बनावट हैरान कर देने वाली हद तक एक जैसी है।

Frontend: जो आपका customer असल में देखता है

Frontend वो सब कुछ है जो किसी के browser में load होता है। Buttons, layouts, fonts, animations, वो तरीका जिससे submit करने के बाद कोई form ख़ुद को साफ़ कर लेता है। अगर आप उसे देख सकते हैं, तो वो frontend है।

Maya के लिए, frontend एक leaderboard है जिसमें rank, name, और referrals की संख्या है। Jordan के लिए, यह classes का एक calendar है जिसमें एक “book” button है। Sam के लिए, यह pastries की एक list है जिसमें हर एक के बगल में छोटे प्लस-और-माइनस buttons हैं।

प्रोजेक्ट के अंदर, frontend आमतौर पर app/, pages/, या src/ जैसे नाम वाले किसी folder में रहता है। आपको ऐसी files दिखेंगी जो .tsx या .jsx पर खत्म होती हैं। हर एक मोटे तौर पर “एक screen” या “किसी screen का एक हिस्सा” है। Leaderboard की row एक file है। Header दूसरी file है। वो page जो सबको आपस में जोड़ता है, तीसरी।

जब आप AI builder से कहते हैं कि “buttons को ज़्यादा गोल बनाओ” या “leaderboard को दाईं ओर ले जाओ,” तो यही हिस्सा बदलता है।

Backend: वो हिस्सा जो सोचता है

Backend वो हिस्सा है जो किसी को नहीं दिखता, पर सब उस पर निर्भर हैं। यह वो कोड है जो कहीं और चलता है — किसी server पर, customer के browser में नहीं — जब कुछ ऐसा होना ज़रूरी हो जिसे अकेले customer के browser पर भरोसा नहीं किया जा सकता।

Browser सब कुछ क्यों नहीं कर सकता? क्योंकि browser customer की मशीन है, और आप उस पर भरोसा नहीं कर सकते। अगर Maya का leaderboard referral counts को सिर्फ़ browser में अपडेट करता, तो कोई भी right-click करके अपने नाम 9,000 referrals जोड़ सकता था। तो backend वो जगह है जहां नियम रहते हैं: “यह इंसान यह कर सकता है, पर वो नहीं,” “इसे सचमुच database में save करो,” “यह email भेजो।”

Backend आमतौर पर api/, server/, या app/api/ नाम वाले folder में रहता है। वहां की files आमतौर पर छोटी होती हैं। हर एक किसी ख़ास request को संभालती है: “एक booking बनाओ,” “आज के croissants की list दो,” “एक referral जोड़ो।”

जब आपकी app में कुछ काम करता है पर नतीजा टिकता नहीं — आप submit क्लिक करते हैं, एक confirmation देखते हैं, पर कल डेटा गायब है — तो bug लगभग हमेशा backend में ही होता है।

Database: आपकी app की याददाश्त

अपनी app की याददाश्त को filing cabinets की एक कतार के रूप में सोचें। हर cabinet पर सामने एक label है। एक पर लिखा है “users।” एक पर “bookings।” एक पर “croissant_orders।” हर cabinet के अंदर, हर drawer एक row है। हर drawer में slots का वही एक सेट है: एक name, एक email, एक created_at, एक status।

वो ढांचा — “कौन से cabinets हैं, हर row में कौन से slots हैं” — schema कहलाता है। यह प्रोजेक्ट की सबसे ज़रूरी file है, भले ही यह शायद देखने में सबसे उबाऊ भी है। schema.ts, schema.prisma, या db/ या migrations/ नाम वाले folder के अंदर कोई file ढूंढें। उसे खोलें। आपको एक list दिखेगी जो उसका आईना है जो आपकी app असल में दुनिया के बारे में याद रखती है।

Jordan के schema में एक classes table, एक bookings table, और एक users table है। Sam के में products, orders, और order_items हैं। Maya के में members और referrals हैं। Schema की बनावट प्रोडक्ट की बनावट है, इसीलिए बाद में इसे बदलना उससे कहीं मुश्किल है कि buttons कैसे दिखते हैं उसे बदलना।

एक काम का तरीका: अगर आप आम शब्दों में बता सकते हैं कि आपकी app क्या याद रखती है, तो आप आमतौर पर schema बता सकते हैं। “मैं हर customer का name और email याद रखता हूं। हर customer के लिए, मैं उनके द्वारा दिए गए orders याद रखता हूं। हर order के लिए, मैं याद रखता हूं कौन सी pastries और हर एक की कितनी।” वो वाक्य, लगभग शब्द-दर-शब्द, schema है।

Auth: दरवाज़े पर खड़ा bouncer

“Auth” दो शब्दों को एक साथ ठूंसकर बना है: authentication (आप कौन हैं?) और authorization (आपको क्या करने की इजाज़त है?)। दोनों आमतौर पर auth/ नाम वाले folder की कुछ files के एक छोटे सेट से संभाले जाते हैं, या किसी ऐसी service से जिसका नाम आप पहचान सकते हैं: Clerk, Auth0, Supabase Auth, NextAuth।

दोनों सवाल अलग हैं। Authentication जवाब देता है: “क्या यह सचमुच Maya है?” — आमतौर पर किसी password, Google login, या उसे email किए गए किसी magic link से। Authorization जवाब देता है: “क्या Maya को दूसरे लोगों के referrals delete करने की इजाज़त है?” — और ज़्यादातर AI से बनी apps के लिए पहले हफ़्ते में खरा जवाब है “हम जांचना भूल गए।”

यह वो हिस्सा है जो सबसे अक्सर चुपचाप टूटा रहता है। Login screen काम करता है, तो यह महफ़ूज़ लगता है। पर backend हमेशा यह नहीं जांचता कि log in किया हुआ इंसान वही इंसान है जिसका डेटा वो पढ़ने की कोशिश कर रहा है। अगर आपकी app में “मेरा डेटा बनाम तुम्हारा डेटा” जैसी कोई भी धारणा है, तो AI builder से साफ़ तौर पर कहें: “पक्का करो कि users सिर्फ़ अपना ही डेटा देख और edit कर सकें।” आप हैरान होंगे कि वो एक वाक्य कितनी बार एक छूटी हुई जांच को उजागर कर देता है।

Integrations: वो चीज़ें जो आपने बनाई नहीं पर फिर भी इस्तेमाल कर रहे हैं

यहीं ज़्यादातर non-developers कम आंकते हैं कि असल में क्या हो रहा है। वो चीज़ जो Sam का “आपके croissants तैयार हैं” वाला email भेजती है, कोड नहीं है — वो SendGrid या Resend पर एक account है। वो चीज़ जो Jordan की class का payment प्रोसेस करती है, कोड नहीं है — वो Stripe है। वो चीज़ जो Maya के leaderboard की photos host करती है, कोड नहीं है — वो S3 या Cloudinary जैसी कोई storage service है।

हर integration दो जगह दिखती है। Backend में कोड का एक छोटा टुकड़ा होता है जो कहता है “अरे Stripe, इस card को charge करो।” और एक key होती है — एक लंबी गुप्त string — जो कहीं महफ़ूज़ जगह स्टोर होती है (आमतौर पर .env नाम की एक file जिसे किसी को कभी commit नहीं करना चाहिए) जो Stripe को साबित करती है कि request Sam की bakery से आई है, किसी अजनबी से नहीं।

अगर आप कभी सोचें कि आपकी app अचानक emails भेजना या payments लेना क्यों बंद कर देती है, तो वजह लगभग हमेशा इनमें से एक होती है: एक expired key, एक पार हो चुकी usage limit, या integration की policies में कोई बदलाव। कोड नहीं टूटा। handshake टूटा।

Deploy: यह इंटरनेट तक कैसे पहुंचता है

आख़िरी हिस्सा वो है जो आपकी disk के folder को एक ऐसी चीज़ में बदलता है जिसे आपका customer किसी URL पर जाकर देख सकता है। इसका आमतौर पर मतलब है तीन छोटी चीज़ें मिलकर काम करना:

• Host: Vercel, Netlify, Fly, या Render जैसी कोई service जो आपका backend चलाती है और आपका frontend serve करती है।
• Domain: mayas-leaderboard.com जैसा कोई नाम जो आपके host की ओर इशारा करता है।
• Build: वो नुस्खा जो आपकी बिखरी हुई source files को लेकर उन्हें उस दुबले, तेज़ वर्शन में बदल देता है जो असल में चलता है।

जब कुछ locally काम करता है पर production में टूट जाता है, तो दिक्कत आमतौर पर यहीं होती है। एक key जो आपके laptop पर सेट है पर host पर नहीं। एक library जो development में install है पर production में नहीं। एक database जो आपके browser में है पर live site पर नहीं।

वो पांच मिनट की आदत जो अपनी कीमत वसूल कर देती है

आपको अपने प्रोजेक्ट की हर file पढ़ने की ज़रूरत नहीं। आपको यह जानने की ज़रूरत नहीं कि उनमें से ज़्यादातर क्या करती हैं। पर आपको, हफ़्ते में एक बार, एक पांच मिनट की पड़ताल करनी चाहिए जिसमें आप ऊपर बताए हर folder को खोलें और AI builder से आम शब्दों में पूछें कि क्या बदला।

Maya यह हर शुक्रवार दोपहर करती हैं। वो टाइप करती हैं: “इस हफ़्ते schema में क्या बदला, और क्यों?” और: “क्या इस app में कोई नई integrations हैं जो मैंने नहीं मांगी थीं?” जवाब लगभग हमेशा तसल्ली देने वाले होते हैं। जिन गिनी-चुनी बार वो नहीं होते, वो दिक्कतों को तब पकड़ लेती हैं जब वो अब भी छोटी हैं।

हिस्सों को समझने का पूरा मकसद यही है। डेवलपर बनना नहीं। बस बेहतर सवाल पूछ पाना।

आगे कहां जाएं

अगर इस टूर से मदद मिली, तो दो follow-ups आपके वक़्त के लायक हैं। ‘सब ठीक दिख रहा है’ वाला bug यह बताता है कि जब इनमें से कोई हिस्सा चुपचाप टूटा हो तो क्या करें, और demo-ready बनाम production-ready यह बताता है कि कैसे पहचानें कि आपकी app पहले स्टेज से दूसरे में पहुंच चुकी है। वही नक्शा, उसके अलग-अलग इस्तेमाल।