2011-06-03 6 views
6

मैंने अपने वेब एप्लिकेशन के लिए JQuery और प्रोटोटाइप जैसे जावास्क्रिप्ट पुस्तकालयों को होस्ट करने के लिए Google APIs जैसे सीडीएन का उपयोग करने के पक्ष में सभी मामलों को सुना है। यह तेज़ है, बैंडविड्थ बचाता है, लिपियों की समांतर लोडिंग की अनुमति देता है, और इसी तरह। लेकिन मैं हाल ही में डगलस क्रॉकफोर्ड की json2.js लिपि में निम्नलिखित टिप्पणी में आया:क्या जावास्क्रिप्ट पुस्तकालयों को लोड करने के लिए सार्वजनिक सीडीएन का उपयोग न करने का कोई फायदा है?

अपनी स्वयं की कॉपी का उपयोग करें। यह उन सेवाओं से कोड लोड करने के लिए बेहद अनजान है जो आप नियंत्रित नहीं करते हैं।

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

+3

Google नीचे चला गया। jQuery वेब के आधा टूटता है। सबसे अच्छा दिन। असफलता के जितने अधिक अंक आपके पास असफल हो जाएंगे। – Raynos

+0

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

उत्तर

10

मान लिया जाये कि वह बारे में बात कर रहा है पेशेवर गूगल जैसे CDNs का आयोजन किया है, तो सबसे अच्छा शर्त यह करने के लिए है:

<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary --> 
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script> 
<script>window.jQuery || document.write("<script src='js/libs/jquery-1.5.1.min.js'>\x3C/script>")</script> 

(http://html5boilerplate.com/ से लिया गया)

इस तरह, आप सभी लाभ मिलता है, बिना यदि Google की सीडीएन नीचे जाती है तो आपकी वेबसाइट को तोड़ने का जोखिम।

लेकिन, उन्होंने कहा:

अपनी प्रतिलिपि का उपयोग। यह बहुत ही सेवा से कोड लोड करने के लिए UNWISE है नियंत्रण न करें।

मुझे नहीं लगता कि वह सीडीएन के बारे में बात कर रहा है। मुझे लगता है कि वह सिर्फ यह कह रहा है "यादृच्छिक वेबसाइटों से स्क्रिप्ट को हॉटलिंक न करें"।

आप ऐसा नहीं करना चाहते हैं क्योंकि वेबसाइट स्क्रिप्ट स्थित है, या यहां तक ​​कि स्क्रिप्ट को बदल सकती है। एक सीडीएन कभी ऐसा नहीं करेगा।

+0

फ़ॉलबैक एक अच्छी तकनीक है, लेकिन केवल आपके नियंत्रण से सर्वर का उपयोग करने के खतरों में से एक से आपको बचाती है। आपके पास अभी भी एक समझौता या दूषित स्क्रिप्ट की सेवा हो रही है। – jball

0

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

दूसरी बार जब आप इसका उपयोग नहीं करना चाहते हैं तो इंट्रानेट एप्लिकेशन परिदृश्य में है, जहां बैंडविड्थ आमतौर पर एक मुद्दा नहीं है।

जॉन गैलोवे से वापस आने बनाने के लिए एक तरह से: http://weblogs.asp.net/jgalloway/archive/2010/01/21/using-cdn-hosted-jquery-with-a-local-fall-back-copy.aspx

<script type="text/javascript" src="http://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js"></script> 
<script type="text/javascript"> 
if (typeof jQuery == 'undefined') 
{ 
    document.write(unescape("%3Cscript src='/Scripts/jquery-1.3.2.min.js' type='text/javascript'%3E%3C/script%3E")); 
} 
</script> 
0

एक सार्वजनिक सर्वर के js समझौता किया है, तो (उपलब्धता, सुरक्षा या बग के लिहाज से), तो आपकी साइट पर आने प्रभावित और संभावना हो जाएगा तुम्हें दोष दिया। दूसरी तरफ, Google की सीडीएन की कुछ छोटी कंपनी के सर्वर की संभावनाओं पर समझौता होने की संभावना क्या है? जब आप स्थानीय रूप से होस्ट करते हैं तो सीडीएन आपको सभी कैशिंग फायदे भी खो देता है।

0

हालांकि इनमें से कुछ अन्य उत्तर निश्चित रूप से मान्य हैं, हमारे पास थोड़ा अलग/अतिरिक्त कारण है।

हमारे पास एक प्रक्रिया है जो पहले अनुरोध पर निर्धारित करती है कि मूल्यांकन किसी भी पृष्ठ के लिए कौन सी स्थिर सामग्री की आवश्यकता है। पृष्ठभूमि में, यह स्थैतिक सामग्री (जेएस, सीएसएस) विलय और एक फ़ाइल में छोटा हो गया है (जेएस के लिए 1, सीएसएस के लिए 1), और फिर सभी भावी अनुरोधों को एकाधिक फाइलों के बजाय एक फ़ाइल के साथ परोसा जाता है।

हम सकता है, सैद्धांतिक रूप से, फ़ाइलों को एक CDN पर परोसा जा सकता है और उन लोगों के लिए CDN का उपयोग को बाहर है, यह आसान हो जाता है (क्योंकि हम वास्तव में होगा बहिष्करण को संभालने के लिए कोड जोड़) और कुछ मामलों में, एक सीडीएन का उपयोग करने से तेज़।

0

jQuery खुला स्रोत है। यदि आपने आंतरिक में संशोधन किया है, तो जाहिर है कि आप किसी अन्य व्यक्ति के सर्वर को होस्ट नहीं कर सकते हैं। आम तौर पर, अन्य लोगों की लिपियों को होस्ट करना एक सुरक्षा जोखिम है; वे कभी भी आपको बताए बिना स्क्रिप्ट बदल सकते हैं, और अब आप इसे अपने पृष्ठों पर जोड़ रहे हैं।

यह विश्वास का विषय है; क्या आप भरोसा करते हैं कि जो भी सीडीएन आपकी इच्छित स्क्रिप्ट के स्थान पर एक दुर्भावनापूर्ण स्क्रिप्ट होस्ट न करने के लिए सुरक्षित होगा?

2

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

0

सभी अन्य उत्तर के अलावा:

आप एक अलग स्रोत से सीधे HTTP पर एसएसएल (अर्थात https) लेकिन अपने जे एस पर अपने पृष्ठों की सेवा के बारे में चिंता करना चाहते हैं। सुरक्षित और असुरक्षित वस्तुओं के बारे में ब्राउज़र शिकायत कर सकते हैं (कभी-कभी खतरनाक तरीके से)।

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

+0

मैं निश्चित रूप से पहले उस परेशान एसएसएल समस्या में भाग गया है। सौभाग्य से Google अब उनके सीडीएन पर https करता है। – Jonathan

+0

मैंने देखा है कि सभी सार्वजनिक सीडीएन (bootcdn.cn को छोड़कर) मैंने https समर्थन किया है। – sgoblin

संबंधित मुद्दे

 संबंधित मुद्दे