मैंने हाल ही में एक अकेली मसाज थेरेपिस्ट के लिए एक वेबसाइट बनाई, जो अपना खुद का क्लिनिक चलाती हैं। यह एक ऐसा प्रोजेक्ट था जिसमें ज़रूरतें बताना तो आसान था, लेकिन अगर आप सब कुछ खुद करने की कोशिश करें तो गलती होने की संभावना भी बहुत ज़्यादा थी: एक आकर्षक लैंडिंग पेज, एक कारगर ऑनलाइन बुकिंग सिस्टम और मालिक के लिए हर बार कुछ बदलने पर मुझे कॉल किए बिना अपने शेड्यूल और ट्रीटमेंट को मैनेज करने का एक तरीका।

हमने Hapio का उपयोग करने का यही तरीका चुना और इसी कारण यह कारगर साबित हुआ।

आरंभिक बिंदु

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

महत्वपूर्ण बात यह है कि वह एक मसाज थेरेपिस्ट हैं, सिस्टम एडमिनिस्ट्रेटर नहीं। हम जो कुछ भी बनाते हैं, वह ऐसे व्यक्ति को समझ में आना चाहिए जो डेटाबेस और एपीआई के संदर्भ में नहीं सोचता है।

हम बुकिंग सिस्टम खुद क्यों नहीं बना लेते?

मैं सकना मैंने एक कस्टम बुकिंग सिस्टम बनाया है। Laravel का उपयोग करके। bookings तालिका, उपलब्ध स्लॉट के लिए कुछ तर्क, टकराव से निपटने का तरीका, उपचारों के बीच का अतिरिक्त समय, बंद दिनों का प्रबंधन, गर्मियों की छुट्टियां...

लेकिन यह ठीक उसी तरह का कोड है जो व्हाइटबोर्ड पर तो सरल दिखता है, लेकिन व्यवहार में छह महीने की जटिल समस्याओं में तब्दील हो जाता है। एक ही संसाधन (एक थेरेपिस्ट), अपवादों के साथ नियमित खुलने का समय, प्रत्येक उपचार से पहले और बाद में बफर, उपचार की अलग-अलग अवधि - यह कोई रॉकेट साइंस नहीं है, लेकिन यह बहुत सारा कोड है जो इस विशेष प्रोजेक्ट के लिए कोई अनूठा मूल्य नहीं जोड़ता है।

Hapio ने यह काम संभाल लिया। हमें उपलब्धता, बुकिंग, सेवाओं और शेड्यूलिंग के लिए एक तैयार API मिल गया। मैं प्रोजेक्ट के असली उद्देश्य पर ध्यान केंद्रित कर सका: एक अच्छी वेबसाइट और एक ऐसी बुकिंग प्रक्रिया जो उनकी अपनी लगे, न कि किसी सामान्य बुकिंग सिस्टम जैसी।

जिस वास्तुकला पर हम पहुँचे

हमने Hapio के चारों ओर एक रैपर के रूप में एक पतला Laravel ऐप बनाया। इसे "फ्रंटएंड + इंटीग्रेशन लेयर" समझें, न कि "पूर्ण बुकिंग सिस्टम"।

हैपियो निम्नलिखित के लिए जिम्मेदार है:

• बुकिंग (बनाना, प्राप्त करना, रद्द करना)
• सेवाएं/उपचार (नाम, अवधि, कीमत, अतिरिक्त समय सीमा)
• नियमित खुलने का समय (सोमवार-रविवार)
• कुछ खास दिनों में बंद रहेगा (छुट्टियों, बीमारी के दिनों आदि के कारण)।
• उपरोक्त सभी के आधार पर उपलब्ध स्लॉट की गणना करना

Laravel निम्नलिखित कार्यों के लिए जिम्मेदार है:

• लैंडिंग पेज और बुकिंग यूआई (लाइववायर)
• अनुसूची, सेवाओं और बुकिंग का अवलोकन करने के लिए व्यवस्थापक पैनल
• ईमेल (पुष्टि, अनुस्मारक, रद्द करने का संदेश - ग्राहक और मालिक दोनों को)
• सुरक्षित रद्दीकरण लिंक (HMAC द्वारा हस्ताक्षरित, ताकि ग्राहक किसी और की बुकिंग में अनजाने में प्रवेश न कर सकें)
• उपलब्ध स्लॉट को कैश करना (Redis)
• Hapio डेटा में परिवर्तन होने पर वेबहुक द्वारा हैंडलिंग

Laravel डेटाबेस में मुख्य रूप से केवल एडमिन उपयोगकर्ता, सेशन और क्यू जॉब्स का डेटा होता है। बुकिंग डेटा स्थानीय रूप से संग्रहीत नहीं होता है। Hapio ही डेटा का विश्वसनीय स्रोत है।

इस आकार के व्यवसाय के लिए यह बिल्कुल सही लगता है। एक छोटा स्थानीय डेटाबेस, एक रेडिस इंस्टेंस, अनावश्यक रखरखाव की कोई आवश्यकता नहीं।

बुकिंग प्रक्रिया

ग्राहक चार चरणों से गुजरता है: उपचार का चयन करें → समय का चयन करें → विवरण भरें → प्रक्रिया पूरी हुई।

पेज लोड होने पर Hapio से उपचार संबंधी जानकारी प्राप्त की जाती है। समय अवधि प्रति सप्ताह के हिसाब से प्राप्त की जाती है - हम इसे Redis में व्यापक रूप से कैश करते हैं क्योंकि यह सबसे अधिक उपयोग किया जाने वाला डेटा है। एक सप्ताह का दृश्य उपलब्ध है जहाँ ग्राहक बारह सप्ताह आगे तक की जानकारी देख सकते हैं।

बुकिंग की पुष्टि होने पर:

1. बुकिंग Hapio में बनाई गई है।
2. ग्राहक की जानकारी (नाम, फ़ोन नंबर, ईमेल, वैकल्पिक संदेश) बुकिंग के मेटाडेटा के रूप में सहेजी जाती है।
3. एक रद्दीकरण लिंक जनरेट किया जाता है (जिसे हमारे नियंत्रण वाली एक गुप्त कुंजी के साथ HMAC द्वारा हस्ताक्षरित किया जाता है)।
4. ईमेल ग्राहक और मालिक दोनों को भेजा जाता है।

बुकिंग रद्द करने की प्रक्रिया हस्ताक्षरित लिंक के माध्यम से होती है – लॉगिन की आवश्यकता नहीं है। हमारा नियम है: आप इससे कम समय में बुकिंग या बुकिंग रद्द नहीं कर सकते। यह नियम हमारे कोड में डेटा पढ़ने के समय लागू होता है, न कि कैश में, इसलिए यह तब भी लगातार काम करता है जब कैश अभी तक खाली नहीं हुआ हो।

व्यवस्थापक पैनल

मालिक लॉग इन करता है और उसके पास चार टैब होते हैं:

• आगामी और पूर्व बुकिंग , जिन्हें रद्द किया जा सकता है।
• अनुसूची – कैलेंडर में किसी भी दिन पर क्लिक करके उसे बंद या खोलें
• खुलने का समय – नियमित साप्ताहिक कार्यक्रम, दिनवार
• सेवाएं – उपचार जोड़ें, संपादित करें, निष्क्रिय करें

सब कुछ Hapio API के माध्यम से होता है। एडमिन पैनल मूल रूप से उनके डेटा मॉडल के ऊपर एक बढ़िया फ्रंटएंड है। जब वह खुलने का समय बदलती है या किसी दिन बंद करती है, तो Hapio एक वेबहुक भेजता है, हम कैश को अमान्य करते हैं, और बैकग्राउंड में समय स्लॉट को फिर से बनाते हैं।

वेबहुक फ्लो को सुदृढ़ बनाने में थोड़ी मेहनत लगी – हस्ताक्षर सत्यापन, आइडमपोटेंसी, गड़बड़ी होने पर पूर्ण कैश फ्लश का फॉलबैक – लेकिन एक बार यह ठीक से काम करने लगा, तो यह मेहनत सार्थक साबित हुई। API को बार-बार चेक किए बिना ही उपलब्ध स्लॉट तुरंत अपडेट हो जाते हैं।

क्या चीज़ें कारगर रहीं

कार्यक्षेत्र का पृथक्करण। हमें बुकिंग संबंधी प्रक्रियाओं को संभालने की आवश्यकता नहीं है। Hapio विवादों, बफर समय और शेड्यूलिंग का प्रबंधन करता है। हम उपयोगकर्ता अनुभव और साइट से संबंधित विशिष्ट कार्यों को संभालते हैं।

वेबहुक्स + कैश। उपलब्ध स्लॉट 24 घंटे के लिए कैश किए जाते हैं। जब हैपियो में कुछ बदलाव होता है (नई बुकिंग, शेड्यूल में बदलाव, नई सेवा), तो एक इवेंट आता है, हम संबंधित कैश को इनवैलिडेट करते हैं और उसे फिर से एक्टिवेट करते हैं। ग्राहकों को अपडेटेड समय दिखाई देता है, इसके लिए हमें हर पेज व्यू पर एपीआई से सब कुछ फ़ेच करने की ज़रूरत नहीं पड़ती।

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

बुकिंग रद्द करने के लिंक। पुष्टिकरण और रिमाइंडर ईमेल में HMAC-हस्ताक्षरित लिंक। ग्राहक को लॉग इन करने या बुकिंग नंबर याद रखने की आवश्यकता नहीं है। बुकिंग रद्द करने की अनुमति देने से पहले हम सर्वर-साइड पर टोकन को सत्यापित करते हैं।

बिना किसी तकनीकी झंझट के प्रशासनिक कार्य। मालिक स्वयं अपना शेड्यूल और सेवाएं प्रबंधित कर सकती हैं। जब वह किसी दिन काम बंद करना चाहे या कोई नया उपचार जोड़ना चाहे, तो मुझे दखल देने की आवश्यकता नहीं है।

जिन चीजों के बारे में हमें सोचना था

SDK और त्रुटि प्रबंधन। हम Hapio के PHP SDK को पाथ डिपेंडेंसी के रूप में उपयोग करते हैं। SDK कभी-कभी PHP चेतावनियाँ देता है जो वास्तविक त्रुटि संदेशों को दबा देती हैं - हमने कॉल को रैप किया और चेतावनियों को दबा दिया ताकि API त्रुटियाँ वास्तव में दिखाई दें।

24 घंटे का नियम। "बुकिंग/रद्दीकरण से कम से कम 24 घंटे पहले" का व्यावसायिक नियम हमारे कोड में पढ़ने के समय लागू होता है, न कि हैपियो में। इसका मतलब है कि कैश में ऐसे स्लॉट हो सकते हैं जो ग्राहक को नहीं दिखाए जाते - डेटा वापस करते समय हम उन्हें फ़िल्टर कर देते हैं। सरल और अनुमानित।

एक संसाधन, एक स्थान। यह कॉन्फ़िगरेशन एक ही स्थान और संसाधन (चिकित्सक) को इंगित करता है। यदि व्यवसाय में कई चिकित्सक या स्थान शामिल हो जाते हैं, तो हमें इस पर पुनर्विचार करना होगा, लेकिन वर्तमान व्यवस्था के लिए यह एकदम सही है।

सारांश

एक छोटे मसाज क्लिनिक के लिए, जिसकी मालकिन को सब कुछ खुद ही संभालना पड़ता है, Hapio एक सही विकल्प था। हमने बुकिंग सिस्टम नहीं बनाया – हमने एक वेबसाइट और एक इंटीग्रेशन लेयर बनाई जो Hapio को इस तरह से सुलभ बनाती है जो व्यवसाय के लिए उपयुक्त हो।

यूआई और ईमेल के लिए Laravel + Livewire का उपयोग। बुकिंग संबंधी सभी लॉजिक के लिए Hapio का उपयोग। कैश के लिए Redis का उपयोग। कैश को सिंक्रनाइज़ रखने के लिए वेबहुक्स का उपयोग।

हैपियो की बदौलत - और इस प्रक्रिया में आई एआई की मदद से - पूरी वेबसाइट को बिल्कुल शुरुआत से बनाने में लगभग एक सप्ताहांत का समय लगा, ताकि वह वास्तव में इसे अपने व्यवसाय के लिए उपयोग करना शुरू कर सके।

यह मेरे द्वारा निर्मित सबसे जटिल वास्तुकला नहीं है, लेकिन यह उन वास्तुकलाओं में से एक है जो परियोजना के लिए सबसे उपयुक्त लगती है। और यही तो आप चाहते हैं।

मसौदा। इसमें जानबूझकर किसी विशिष्ट स्थल, स्थान या व्यक्ति का उल्लेख नहीं किया गया है।