Caching म्हणजे काय? ॲप बिल्डर्ससाठी सोपे मार्गदर्शक

Caching म्हणजे मिळवायला धीमी किंवा महाग असलेल्या गोष्टीची तयार प्रत ठेवणे, जेणेकरून त्याची पुढची request त्या प्रतीवरून जलद उत्तर देता येईल. जतन केलेल्या प्रतीला cache म्हणतात. तुमचा ब्राउझर प्रतिमा cache करतो, त्यामुळे दुसऱ्या भेटीत साइट जलद उघडते; सर्व्हर एखाद्या धीम्या डेटाबेस क्वेरीचा निकाल cache करतो, म्हणजे प्रत्येक भेट देणाऱ्यासाठी ती क्वेरी पुन्हा चालवावी लागत नाही.

Caching ॲप्स जलद आणि चालवायला स्वस्त करते. त्याचा एक मोठा तोटा म्हणजे प्रत जुनी होऊ शकते.

AI सह बनवताना Caching का महत्त्वाचे आहे

AI-built ॲप्समध्ये caching तीन प्रकारे समोर येते:

• "मी ॲप अपडेट केले पण अजूनही जुनी आवृत्ती दिसते." Caching चा हा सर्वात सामान्य प्रसंग आहे, आणि सहसा तो निरुपद्रवी असतो — तुमचा ब्राउझर किंवा CDN जतन केलेली प्रत दाखवत असतो.
• वेग. जर एखादे पेज प्रत्येक भेट देणाऱ्यासाठी एकच आकडेमोड पुन्हा करत असल्यामुळे धीमे असेल, तर निकाल cache केल्याने ते तात्काळ वाटू शकते.
• खर्च. अनेक AI बिल्डर्स आणि hosts compute, डेटाबेस वेळ आणि बाहेरील API calls वर शुल्क आकारतात. हजार भेट देणाऱ्यांनी एकच महाग request केली, तर caching मुळे तुम्ही ती एकदाच भरता.

मूलभूत गोष्टी माहीत असल्यास caching कुठे उपयोगी आहे हे विचारता येते, आणि ते चुकीच्या गोष्टीचे कारण असताना ओळखता येते.

दैनंदिन उदाहरण

एका गजबजलेल्या कॅफेच्या स्वयंपाकघराचा विचार करा.

प्रत्येक सकाळी शेफ प्रत्येक कॉफी मागणी आल्यावर ताज्या दळलेल्या बियांपासून बनवू शकतो. ते धीमे आहे. त्याऐवजी ते गरम प्लेटवर फिल्टर कॉफीचे एक भांडे तयार ठेवतात. बहुतेक ग्राहकांना काही सेकंदांत कप मिळतो — तो cache hit आहे. भांडे संपले की कोणी नवीन बनवतो — तो cache miss आहे.

पण जास्त वेळ ठेवलेली कॉफी शिळी होते, म्हणून कॅफेचा नियम आहे: ३० मिनिटांपेक्षा जुने कोणतेही भांडे फेकून द्या. तो नियम म्हणजे cache ची expiry वेळ. कोणीही दिवसभर एकच भांडे ठेवणार नाही, आणि कोणाच्या खास ऑर्डरसाठी (ओटमिल्कसह आणि तीन साखरेसह) आधीच बनवून ठेवणार नाही — काही गोष्टी अजिबात cache करू नयेत.

Caches कुठे राहतात

एका पेज लोडमध्ये अनेक caches मधून जाऊ शकते, वापरकर्त्याच्या सर्वात जवळपासून सर्वात दूरपर्यंत:

A CDN (content delivery network) म्हणजे तुमच्या साइटच्या फाइल्ससाठी जगभरातील caches चे नेटवर्क.

Cache काय ठेवायचे ते कसे ठरवते

प्रत्येक cache ला हे प्रश्न सोडवावे लागतात:

• काय cache करता येते? सार्वजनिक, सामायिक डेटा (उत्पादनाची प्रतिमा, ब्लॉग पोस्ट) — हो. खाजगी डेटा (वापरकर्त्याचे खाते पेज, त्याचे संदेश) — सामायिक cache मध्ये कधीच नाही.
• किती काळासाठी? याला TTL (time to live) म्हणतात. लोगो वर्षभर cache होऊ शकतो; स्टॉक पातळी ३० सेकंद.
• ती कशी अपडेट होते? एकतर प्रत कालबाह्य होते आणि पुन्हा आणली जाते, किंवा डेटा बदलल्यावर ॲप ती हेतुपुरस्सर काढून टाकते — याला invalidation म्हणतात.

वेबसाइट्ससाठी सर्व्हर प्रत्येक फाइल ब्राउझर आणि CDN ने कशी cache करावी हे Cache-Control header द्वारे सांगतो. उदाहरणार्थ, Cache-Control: max-age=3600 म्हणजे "तुम्ही ही प्रत एक तास पुन्हा वापरू शकता."

आधुनिक build tools स्थिर फाइल्ससाठी सर्वात कठीण भाग cache busting द्वारे हाताळतात: फाइल बदलली की तिला fingerprint असलेले नवीन नाव मिळते, जसे app.3f9a2c.js. जुन्या नावाची प्रत ब्राउझर बराच काळ cache करू शकतो, कारण नवीन आवृत्तीचे नाव वेगळे असते.

एक उदाहरण: उत्पादन कॅटलॉग

तुमचे एक छोटे ऑनलाइन दुकान आहे. मुख्य पेजवर डेटाबेसमधील ५० उत्पादने, किंमती आणि स्टॉक पातळी दाखवली जाते, तसेच सर्व ऑर्डर्सवर एक धीमी आकडेमोड करणारी "trending" यादी.

१. प्रतिमा आणि scripts ब्राउझर आणि CDN बराच काळ cache करतात. प्रत्येक नवीन build बदललेल्या फाइल्सना नवीन नावे देतो, त्यामुळे अपडेट्स तरीही दिसतात. २. Trending यादी दर १० मिनिटांनी एकदा मोजली जाते आणि application cache मध्ये ठेवली जाते. त्या १० मिनिटांतील प्रत्येक भेट देणाऱ्याला जतन केलेला निकाल तात्काळ मिळतो. ३. किंमती थोड्या वेळासाठी cache होतात, आणि तुम्ही उत्पादन संपादित केल्यावर cache साफ होतो, त्यामुळे ग्राहकांना जुनी किंमत जास्त वेळ दिसत नाही. ४. चेकआउटवरील स्टॉक कधीच cache होत नाही. कोणी "Buy" दाबल्यावर ॲप खरा डेटाबेस तपासते, त्यामुळे नुकताच संपलेला माल विकला जाऊ शकत नाही. ५. कार्ट आणि खाते पेजेस सामायिक caches मध्ये कधीच साठवली जात नाहीत, कारण ती वैयक्तिक असतात.

परिणाम: मुख्य पेज जलद आहे, डेटाबेसचे काम खूप कमी होते, आणि पैसे किंवा गोपनीयतेशी संबंधित काहीही कधीच कालबाह्य नसते.

महत्त्वाचे शब्द

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

• "Caching नेहमी चांगले असते." चुकीची गोष्ट cache केल्याने खरे बग येतात: जुन्या किंमती, नवीन पोस्ट्स न दिसणे, किंवा सर्वात वाईट — एका वापरकर्त्याचे खाजगी पेज दुसऱ्याला दिसणे. जाणूनबुजून cache करा.
• "जुनी आवृत्ती दिसली तर माझे अपडेट अयशस्वी झाले." सहसा तसे नसते. काहीतरी तुटले आहे असे समजण्यापूर्वी hard refresh (Windows वर Ctrl+Shift+R, Mac वर Cmd+Shift+R) किंवा private window वापरून पहा.
• "Caching ने धीमे ॲप ठीक होते." ते वारंवार येणाऱ्या requests साठी धीमेपणा लपवते. पहिली request तरीही धीमी असते, आणि मूळ समस्या डेटाबेस इंडेक्स नसणे असेल तर तेही दुरुस्त करा.
• "शक्य तितका जास्त काळ सर्वकाही cache करावे." लांब cache वेळ अशा फाइल्सना योग्य आहे ज्या बदलल्यावर नवीन नाव घेतात. HTML पेजेस आणि डेटासाठी कमी वेळ सुरक्षित आहे.
• "Cache साफ केल्याने सर्वांसाठी ठीक होते." ते फक्त तुमचा ब्राउझर साफ करते. भेट देणारे आणि CDN caches अजूनही त्यांच्या प्रती ठेवतात.

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

• "या ॲपचे कोणते भाग धीमे आहेत, आणि कोणते सुरक्षितपणे cache करता येतील?"
• "[ट्रेंडिंग यादी / API निकाल] [N] मिनिटांसाठी cache करा, आणि मूळ डेटा बदलल्यावर ती साफ करा."
• "वैयक्तिक किंवा खाते डेटा असलेले कोणतेही पेज CDN किंवा सामायिक cache द्वारे cache होऊ शकणार नाही याची खात्री करा."
• "Fingerprint असलेल्या स्थिर फाइल्ससाठी लांब cache वेळ आणि HTML साठी लहान वेळ सेट करा."
• "[बाहेरील API] कडील प्रतिसाद cache करा, म्हणजे प्रत्येक पेज लोडवर तो कॉल होणार नाही — आणि हा डेटा किती जुना होऊ शकतो ते सांगा."
• "प्रकाशित केल्यानंतर मला जुनी आवृत्ती दिसते. ते माझा ब्राउझर cache आहे, की काहीतरी deploy झालेले नाही?"

Mythex मधील Caching

Mythex ॲप अपडेट प्रकाशित केल्यानंतर, docs नुसार CDN caches काही काळ मागे राहू शकतात, आणि सार्वजनिक URL चा hard refresh नवीन आवृत्ती दाखवतो — पहा How to publish. Hosting limits पेज स्थिर assets cache करण्याची शिफारस करते, कारण hosting, डेटाबेस वेळ आणि bandwidth तुमच्या credit balance मधून भरले जातात. त्यापलीकडे — क्वेरी निकाल किंवा API प्रतिसाद cache करणे — हे तुम्ही एजंटला तुमच्या ॲपमध्ये तयार करायला सांगता.

संबंधित वाचन: CDN म्हणजे काय, तुमची वेबसाइट जलद कशी करावी आणि rate limiting म्हणजे काय.

प्रश्न