क्या आपको हमेशा वेबसाइट के लिए सर्वर साइड प्रोग्राम करना चाहिए?


38

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

क्या यह पर्याप्त है? क्या मैं बस होस्ट करने के लिए HTML, CSS और JS फाइल अपलोड कर सकता हूं और इसके साथ किया जा सकता हूं, या क्या मुझे नोड या PHP में बैकएंड सर्वर प्रोग्राम करने के लिए समय लेना चाहिए?


54
यह प्रयाप्त है? आपको क्या समस्या है कि गतिशील बैक एंड होने से हल हो जाएगा। जब तक आप नहीं कर सकते, तब तक इसे सरल रखें।
रबरडुक

25
नहीं किए गए काम को अधिकतम करें। YAGNI।
रबरडैक

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

11
मुझे आश्चर्य है कि इस तरह के एक सवाल को इतने सारे उभार क्यों मिले हैं? यह पूछने की तरह है "क्या मुझे अपने सॉफ़्टवेयर के लिए एक डेटाबेस बनाना होगा, भले ही इसके लिए कोई डेटा संग्रहीत करने की आवश्यकता न हो?"। यह मुझे आश्चर्य नहीं होगा अगर यह एक शुरुआती सवाल था, लेकिन तब नहीं जब आप बूटस्ट्रैप / फाउंडेशन प्रोजेक्ट बनाने के लिए पर्याप्त कुशल हों।
महदी

14
@ मेहदी इस वजह से उठी है क्योंकि हर कोई 5 साल से इस सटीक लानत को सोच रहा है और किसी को भी यह पूछने की हिम्मत नहीं हुई है।
djechlin

जवाबों:


86

यदि आपको नहीं पता कि आपको सर्वर-साइड कोड की आवश्यकता है, तो आप संभवतः नहीं *

* चेतावनी : सर्वर-साइड कोड सुरक्षा के लिए आवश्यक है, जब आप सामग्री, डेटा या कार्यक्षमता तक आंतरिक रूप से नियंत्रण करना चाहते हैं। (यह जरूरी नहीं कि आपका सर्वर हो, अंतिम पैराग्राफ देखें।)

अपने आप से पूछें कि सर्वर-साइड प्रौद्योगिकियों का उपयोग करने से क्या समस्या हल होगी। यदि आप किसी के बारे में नहीं सोच सकते हैं (और आपके मामले में, मैं भी नहीं कर सकता) तो आपको उनकी आवश्यकता नहीं है।

ध्यान रखें कि क्लाइंट-साइड कोड का उपयोग करके आप जितना सोच सकते हैं, उससे कहीं अधिक संभव है। AngularJS या ReactJS जैसे जावास्क्रिप्ट फ्रेमवर्क आपको एपीआई के अजाक्स के माध्यम से तीसरे पक्ष, गतिशील सामग्री के साथ एकीकृत कर सकते हैं। (इसमें एक एपीआई को हुक करना शामिल है जो अपनी स्वयं की सुरक्षा को संभाल सकता है।)


17
मुझे लगता है कि यह बनाने के लिए एक खतरनाक बयान है - सर्वर साइड प्रौद्योगिकियों का उपयोग अक्सर तब किया जाता है जब आप 'इसे क्लाइंट साइड कर सकते हैं': सर्वर पर चीजों को स्थानांतरित करने का निर्णय सुरक्षा कारणों से होता है, जरूरी नहीं कि कार्यात्मक वाले। - जैसे कि 'न जानने' का एक दृष्टिकोण को बढ़ावा देना चिंताजनक है: प्रोग्रामर को हमेशा किसी भी आवेदन में सुरक्षा पर विचार करना चाहिए , यहां तक ​​कि एक सरल रूप में वर्णित है। संपूर्ण समाधान के माध्यम से सोचा जाना चाहिए - क्या आप एक 'सुरक्षित' सामग्री क्षेत्र चाहते हैं, जिससे उपयोगकर्ताओं को पंजीकरण करने के लिए मजबूर किया जा सके या उन्हें एमपी 3 देने से पहले एफबी पर पसंद किया जा सके? (हालांकि इस उदाहरण में, एक स्थिर साइट ठीक आवाज करती है)
जेमन्स

3
स्थैतिक साइट जनरेटर के सुरक्षा लाभों के लिए भी कुछ कहा जाना है। कई अनुप्रयोगों के लिए, स्थैतिक साइटें सुरक्षा में अंतिम होती हैं, क्योंकि वहां वास्तव में हैक करने के लिए कुछ भी नहीं है।
नाथन गोफंडमोनिका आर्थर

1
Server-side code is essential for securityकाफी कुछ डेवलपर्स सुरक्षा के बारे में af * ck नहीं देते हैं। तब तक नहीं जब तक आप उनके चेहरे को अपनी ... गन्दगी में नहीं फेंक देते। मेरी लाइन यह है कि अगर आपको प्रमाणीकरण की आवश्यकता है, तो आपको एक बैक ऑफिस की आवश्यकता है। यदि आपको डेटा संग्रहीत करने की आवश्यकता है, तो आपको एक बैकऑफ़िस की आवश्यकता होती है, जहाँ क्लाइंट की ओर से जाँच की गई दूसरी बार डेटा की जाँच की जाएगी।
14 फरवरी को Walfrat

1
@Walfrat यदि आपको केवल प्रमाणीकरण की आवश्यकता है, तो आप इसे किसी भी ओपन सर्विस की किसी भी संख्या में लोड कर सकते हैं और किसी भी बैकएंड का उपयोग नहीं कर सकते हैं। यदि आपको प्राधिकरण की आवश्यकता है, तो दूसरी ओर, आपको कुछ बैकएंड सामान की आवश्यकता हो सकती है।
corsiKa

56

स्थैतिक साइट जनरेटर के बारे में पढ़ें। ये आपको प्रोग्रामेटिक तरीके से (टेम्प्लेट, डेटा, आदि का उपयोग करके) साइट बनाने की अनुमति देते हैं, और HTML को हाथ से लिखने से नहीं। परिणाम स्थिर HTML और CSS का एक सेट है जिसमें किसी भी बैकएंड की आवश्यकता नहीं होती है।

https://www.staticgen.com/ कई ऐसे ओपन-सोर्स जनरेटर की सूची और रैंक करता है; बंद-स्रोत प्रसाद की संभावना भी मौजूद है।


3
+1, यह अभी भी डायनामिक साइटों के लिए काम करता है जो कि थोड़े समय के लिए (जैसे ब्लॉग और यात्रा कार्यक्रम)। जब तक सामग्री पृष्ठ को देखने वाले उपयोगकर्ता पर निर्भर करती है, तब तक यह अक्सर पर्याप्त होता है।
रेमकोगर्लिच

1
+1। टूर की तारीखें और उदाहरण के गीतों को क्लाइंट को कम या ज्यादा बार अपडेट करना होगा। एक स्थिर साइट जनरेटर एचटीएमएल को छूने की आवश्यकता से बचता है, और यह एक (खराब बनाए रखा) सीएमएस की तुलना में बहुत सरल और सुरक्षित है।
बेर्गी

3
जबकि मैं सहमत हूं कि यह ओपी के लिए एक अच्छा सुझाव है, क्या यह वास्तव में पूछे गए प्रश्न का उत्तर देने का प्रयास करता है?
वुडरो बारलो

चिह्नित उत्तर अधिक सामान्य था और इस प्रश्न के साथ गठबंधन किया गया था जैसे कि वुड्रो बार्लो उल्लेखों के अनुसार। हालाँकि मैंने एक अच्छा समाधान पूर्व निर्धारित करने के लिए +1 किया था और कई अन्य लोग इसके लिए जा सकते थे
Deegriz

2
@WoodrowBarlow: मैं बहस चाहते हैं कि Can I simply upload HTML, CSS, and JS files to a host and be done with it, or should I take the time to program a backend server in Node or PHP?:) ओर इशारा करते हुए एक 3, ओपी के मामले में नहीं बल्कि आकर्षक होता है, विकल्प IMHO के लिए कॉल करता है
Tobia Tesan

6

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

आप सोच सकते हैं, कोई भी उस साइट को हैक नहीं करना चाहेगा। लेकिन आम सीएमएस सिस्टम में पाए जाने वाले सामान्य सुरक्षा छेदों के लिए, जल्द ही स्वचालित बॉट होते हैं जो वेब को क्रॉल / खोजते हैं और उस सीएमएस का उपयोग करके सभी साइटों को हैक करते हैं। वे केवल अपने लिंक / मैलवेयर / प्रचार प्रसार करना चाहते हैं।

एक स्थैतिक साइट के साथ (मैन्युअल रूप से या जनरेटर के साथ बनाया गया), आपको वह समस्या नहीं है।

यदि आप अपने स्वयं के बैकएंड को लागू करते हैं, तो इसमें सुरक्षा छेद भी होंगे (कोई भी पूर्ण नहीं है) लेकिन सबसे अधिक संभावना है कि कोई भी इस छोटी सी वेबसाइट के लिए उनका शोषण नहीं करेगा। लेकिन आप क्या लागू करना चाहते हैं? यदि आप एक ऐसा संपादक बनाना चाहते हैं, जहाँ आपका मित्र स्वयं भ्रमण तिथियों को बदल सकता है, तो सोचिए कि यह आपको कितना समय लगेगा जब तक कि वह आपकी सहायता के बिना उपयोग करना आसान न हो। आप कितनी बार बस उस समय के बजट के साथ उसके लिए तारीखों को जल्दी से बदल सकते हैं?

मेरी राय में, अब तक बहुत से लोग आज हर साइट के लिए सीएमएस सिस्टम का उपयोग करते हैं, क्योंकि स्थिर HTML "पुराना" है। यदि आपको HTML5 के साथ कुछ भी संभव नहीं है, तो सर्वर साइड कोड का उपयोग करें। लेकिन अगर आपको इसकी आवश्यकता नहीं है, तो आप इसके बिना बहुत समय बचाते हैं।


हर कुछ सप्ताह? हह, अगर केवल! अधिक दिनों की तरह
मोनिका

3

जरूरत पड़ने पर आपको केवल बैकएंड प्रोग्रामिंग करने की जरूरत है।

हालांकि यहां तक ​​कि ईमेल की तरह बुनियादी सुविधाओं के लिए आमतौर पर बुनियादी बैकएंड प्रोग्रामिंग की आवश्यकता होती है। अगर यह सिर्फ एक प्रदर्शन साइट है तो हाँ, यह ठीक है।


1
यदि यह सिर्फ एक सरल विशेषता है, तो आप इसे बदलने के लिए अक्सर कुछ सास सेवा का उपयोग कर सकते हैं, हालांकि। उदाहरण के लिए, Google फ़ॉर्म पर एक पंजीकरण फॉर्म मुफ्त में किया जा सकता है , और फिर साइट से लिंक किया जा सकता है ।
एंड्रे परमेस

2

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

कई साइटों पर एक ही मेनू, हेडर और कई पृष्ठों पर पाद लेख तत्व होते हैं। यदि आप बस एक पेज से दूसरे पेज पर इनको कॉपी और पेस्ट करते हैं तो यह शायद थकाऊ हो जाता है और साइट के बड़े होने पर त्रुटि हो जाती है और आपको इन क्षेत्रों में बदलाव करते रहना होगा।

सर्वर साइड प्रोग्रामिंग से पहले के दिनों में यह पता करने का एक सामान्य तरीका था कि इन क्षेत्रों को हर पृष्ठ पर एम्बेड करने के लिए फ़्रेम का उपयोग किया जाए । यह कई साल पहले अनुकूल हो गया था, इसलिए मैं इसे अभी करने की सलाह नहीं देता। आप प्रत्येक पृष्ठ पर इन सामान्य तत्वों को प्रदर्शित करने के बजाय कुछ सरल सर्वर साइड कोड लिख सकते हैं।

मैं यहाँ उन अन्य लोगों से सहमत हूँ जिन्होंने शेल्फ सीएमएस का उपयोग करने की सिफारिश की है।


1
"प्रतिलिपि और चिपकाने" का एक विकल्प एक स्थिर साइट जनरेटर का उपयोग करना है; आपके लिए मेनू / हैडर / पाद लेख तत्वों का ध्यान रखना चाहिए, जिससे आप सामग्री के बारे में चिंता कर सकते हैं।
Doktor J
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.