एक फ्रंटएंड केंद्रित व्यक्ति के रूप में, जो समय-समय पर नोड.जेएस भी करता है, एक्सियोस मेरा जाना रहा है।
फेसबुक से आसान एपीआई, ब्राउज़र और नोड पर काम करता है? पूर्ण

@mikeal के साथ हाल ही में हुई एक चर्चा के अनुसार, मैंने कोशिश करने के लिए बेंट किया है। एक Node.js डेवलपर के रूप में, जो कुछ समय से अनुरोध का उपयोग कर रहा है, बेंट निश्चित रूप से एक आसान संक्रमण था - अत्यधिक अनुशंसित

@reconbot आप मिला , सुई और urllib जोड़ना चाहेंगे।

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

मैंने इसके बारे में एक लेख भी लिखा था। सामान्य विचार यह है कि सभी को अपने स्वयं के HTTP क्लाइंट बनाने के लिए प्रोत्साहित किया जाता है, विशेष रूप से उनकी अपनी आवश्यकताओं के अनुरूप।

बंडल आकार के लिए, मुझे नहीं पता, लेकिन यह बहुत छोटा होना चाहिए, हालांकि इस क्लाइंट को कभी भी ब्राउज़र में उपयोग करने के लिए डिज़ाइन नहीं किया गया था।

तालिका में निम्नलिखित कॉलम जोड़ना अच्छा हो सकता है:

• गिथब में सितारों की संख्या (हाँ, मुझे पहले से ही पता है कि यह एकमात्र कारक नहीं है जब एक काम का चयन किया जाता है)
• एनपीएम डाउनलोड की संख्या (शायद साप्ताहिक, एनपीएम वेबसाइट के समान स्टेट, और हां, मुझे पहले से ही पता है कि यह एकमात्र कारक नहीं है जब एक लिब चुनते हैं)

इन नंबरों को साथ-साथ रखने पर कुछ कामों में हजारों सितारे और लाखों डाउनलोड साप्ताहिक होते हैं, जबकि अन्य सैकड़ों में होते हैं।

मेरे 2 सेंट, अनदेखा करने और आगे बढ़ने के लिए ठीक है, टिप्पणी को सही करने या विवाद करने की कोई आवश्यकता नहीं है।

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

axios को मेरा वोट मिलता है, खासकर फ्रंट-एंडर के रूप में।

देखने लायक: ky (फ्रंटएंड) और ky-universal (आइसोमोर्फिक)

Axios उपयोगकर्ता यहाँ। इस तरह, हमारी सभी टीमें पर्यावरण की परवाह किए बिना एक ही पुस्तकालय का उपयोग कर सकती हैं: ब्राउज़र या नोडज (सर्वर या सर्वर रहित में चल रहा है)। बहुत अच्छी तरह से बनाए रखा, और हमारे सभी लोग इसे पसंद करते हैं।

हमारे पास got रीडमी में got , request , node-fetch , axios , और superagent के बीच एक अच्छी तुलना है : https://github.com/sindresorhus/got#comparison
(यदि आप कोई अशुद्धि देखते हैं तो पीआर का स्वागत है। हमने इसे यथासंभव तटस्थ रखने की कोशिश की है)

request से आगे बढ़ने के लिए गॉट के पास माइग्रेशन गाइड भी है: https://github.com/sindresorhus/got/blob/master/migration-guides.md

मेरे लिए, मैं एपीआई लाने के आसपास रैपर करता हूं, इसलिए नोड-फ़ेच मेरा गोटो है। नकारात्मक पहलुओं के बावजूद, मैं आमतौर पर इसे नोड में global.fetch पर लोड करता हूं, इसलिए मैं इसे हमेशा उपलब्ध होने पर भरोसा कर सकता हूं, जैसे ब्राउज़र में (पुराने ब्राउज़रों के लिए पॉलीफिल के माध्यम से)। isomorphic-fetch का भी उपयोग कर सकते हैं जो नोड के लिए नोड-फ़ेच के चारों ओर एक रैपर है, और ब्राउज़र में फ़ेच पॉलीफ़िल (या पहले से उपलब्ध फ़ेच) है। चूंकि मुझे विरासत ब्राउज़रों का समर्थन करने की आवश्यकता नहीं है, इसलिए मैं केवल वैश्विक का उपयोग करता हूं, और नोड में उपयोग के लिए वैश्विक स्थापित करता हूं।

अरे, मलबे (https://www.npmjs.com/package/wrec) मैं क्या उपयोग करता हूं

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

@Velveeta मैं गया और अक्ष कोडबेस को देखा और कोई सबूत नहीं देखा कि यह "निचले स्तर के मानक अनुरोध पुस्तकालय" पर आधारित है। कृपया मुझे बताएं कि आप इस निष्कर्ष पर कैसे पहुंचे?

@sindresorhus की तुलना उपरोक्त मेरी सूची से कहीं बेहतर दृष्टिकोण है। https://github.com/sindresorhus/got#comparison

node-fetch/isomorphic-fetch अधिकांश ग्राहकों के लिए एक उपयुक्त निम्न स्तरीय बिल्डिंग ब्लॉक है। मुझे एक भ्रूण आधारित अनुरोध शिम देखना अच्छा लगेगा।

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

@mikeal द्वारा स्वयं r2 है। इसे request का आध्यात्मिक उत्तराधिकारी माना जाता है। इसमें एक प्रॉमिस एपीआई है और यह 16kb कंप्रेस्ड है।

ब्राउज़र में Axios ठीक काम कर सकता है, लेकिन Node.js पर इसके साथ हमारा अनुभव ऐसा नहीं रहा है। साथ ही, मुझे यकीन नहीं है कि इसे अब सक्रिय रूप से बनाए रखा गया है या नहीं।

@ kreig303 मैंने अक्षतंतु के आंतरिक भाग में नहीं देखा है, इसलिए मुझे इसकी जानकारी नहीं थी। ऐसा लगता है कि यह वर्तमान में नियमित एक्सएचआर पर आधारित है, जो समझ में आता है, क्योंकि यह क्लाइंट और सर्वर दोनों अनुरोधों का समाधान है। मेरा सीधा सा मतलब था कि एक्सियोस बहुत अधिक समृद्ध है, और कुछ और अधिक नंगे हड्डियों को एक मूलभूत मॉड्यूल के लिए विचार किया जाना चाहिए जैसे अनुरोध के प्रतिस्थापन, और फिर यदि वे चाहें तो अन्य अधिक फीचर समृद्ध libs को उसके ऊपर बनाने दें। मैंने कुछ ऐसा चुना है जो विशेष रूप से क्लाइंट और सर्वर दोनों पर एक सतत एपीआई रखने के उद्देश्यों के लिए फ़ेच एपीआई को प्रतिबिंबित करता है (जैसे एक्सएचआर के अंतर्निहित अक्ष), और क्योंकि यह एक्सएचआर के तार्किक उत्तराधिकारी है। यदि एक अच्छा एपीआई रैपर वांछित है, तो इसे लपेटने और उस इष्टतम एपीआई के साथ एक और पुस्तकालय जारी करने का बहुत अवसर है, लेकिन मैं क्लाइंट और सर्वर के बीच फीचर और एपीआई समानता के लिए सभी के लिए हूं जहां भी यह किया जा सकता है।

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

खैर, मुझे लगता है कि एक्सियोस का एक ही विश्वास है ..

तो इसके बजाय हम क्या कर सकते हैं, यह समझने में कम से कम कुछ प्रयास करें कि पहिया कैसे काम करता है, और फिर प्रत्येक व्यक्तिगत कार्य के बारे में सोचने की कोशिश करें, और देखें कि कौन सा पहिया सबसे अच्छा फिट बैठता है।

@ofrobots इस तरह के एक लोकप्रिय रूप से उपयोग की जाने वाली लाइब्रेरी के लिए एक चुनिंदा स्क्रीनशॉट है। ये मेरा:

एफडब्ल्यूआईडब्ल्यू मुझे याद नहीं है कि क्या मैंने इसे बैक-एंड लिब के रूप में इस्तेमाल किया था, इसलिए मैं आपके दावों को सत्यापित करने की स्थिति में नहीं हूं (जब तक कि आपके पास एक असाधारण उपयोग मामला नहीं था जिसमें यह शामिल नहीं था)।

@Velveeta मैं देख रहा हूँ कि आप इसके साथ कहाँ जा रहे हैं, मुझे नहीं पता कि मेटा-लिब्स जाने का रास्ता है या नहीं।

फ्रंटएंड से मेरा वोट axios के लिए है। छोटा, स्थिर और अनुमानित।

मैं व्यक्तिगत रूप से अपने एफई- और बीई परियोजनाओं दोनों के लिए नीच का उपयोग करता हूं - मुख्य रूप से क्योंकि एपीआई वास्तव में सहज है।

फ़ेच के चारों ओर एक आवरण - नोड-फ़ेच के साथ भी अच्छी तरह से काम करता है।

उन लोगों के लिए जो axios जैसा अनुभव चाहते हैं fetch API के शीर्ष पर, gaxios है। यह Google के एक डेवलपर द्वारा बनाया गया था और वर्तमान में Google API के Node.js क्लाइंट के सभी HTTP इंटरैक्शन को शक्ति प्रदान करता है, इसलिए इसे युद्ध परीक्षण और सक्रिय रूप से उपयोग करने पर विचार करना सुरक्षित लगता है!

(👋 @JustinBeckwith पर)

अरे, मलबे (https://www.npmjs.com/package/wrec) मैं क्या उपयोग करता हूं

यह hapijs ढांचे के लिए अंतर्निहित http क्लाइंट भी है। कार्यान्वयन बूट करने के लिए बहुत साफ है।

@mikeal द्वारा स्वयं r2 है। इसे request का आध्यात्मिक उत्तराधिकारी माना जाता है। इसमें एक प्रॉमिस एपीआई है और यह 16kb कंप्रेस्ड है।

उस पुस्तकालय का रखरखाव नहीं किया जाता है। यदि आप एक समान एपीआई चाहते हैं, तो मैं ky की अनुशंसा करता हूं, जो कि ~1kb छोटा और gzipped है, और got के समान लोगों द्वारा बनाए रखा जाता है।

ब्राउज़र में Axios ठीक काम कर सकता है, लेकिन Node.js पर इसके साथ हमारा अनुभव ऐसा नहीं रहा है। साथ ही, मुझे यकीन नहीं है कि इसे अब सक्रिय रूप से बनाए रखा गया है या नहीं।

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

एक फ्रंटएंड केंद्रित व्यक्ति के रूप में जो समय-समय पर नोड जेएस भी करता है, सिद्धांतों का मेरा जाना रहा है। फेसबुक से आसान एपीआई, ब्राउज़र और नोड पर काम करता है? पूर्ण

मुझे नहीं पता था कि यह फेसबुक था? लेकिन हाँ, यह सभी एपीआई एक्सेस के लिए मेरी गोटो लाइब्रेरी है।

हम इस पुस्तकालय का उपयोग करते हैं टिंकऑफ-अनुरोध https://github.com/TinkoffCreditSystems/tinkoff-request। छोटा, ब्राउज़र और सर्वर पर काम करता है और प्लग-इन की अवधारणा पर बनाया गया है। पुस्तकालय कई प्रकार के जटिल कैशिंग के एक साथ उपयोग की अनुमति देने के लिए बनाया गया था।

क्या किसी ने माइक्रोसॉफ्ट से टाइप-रेस्ट-क्लाइंट का इस्तेमाल किया था? ऐसा लगता है कि टाइपस्क्रिप्ट में लिखा गया अच्छी तरह से बनाए रखा पैकेज (मेरे लिए यह एक बड़ा प्लस है)।

इसमें wreck ( hapi पारिस्थितिकी तंत्र से) शामिल होना चाहिए

मैं हाल ही में बड़ी सफलता के साथ https://github.com/grantila/fetch-h2 का उपयोग कर रहा हूं

क्या वर्तमान में कोई ज्ञात संगत ड्रॉप-इन प्रतिस्थापन है? यह केओए में एकीकृत है और मुझे स्ट्रीम-परेशानी दे रहा है

जैसा कि अंक की शुरुआत में उल्लेख किया गया था, मैं एक अन्य पुस्तकालय पर काम कर रहा हूं जिसे अब मैं bent नामक उपयोग करना पसंद करता हूं।

कुछ समय से bent को ब्राउज़र में काम करने के लिए डिज़ाइन नहीं किया गया है। चूंकि एपीआई अब काफी स्थिर है, इसलिए मैंने fetch के शीर्ष पर एक ब्राउज़र संस्करण लिखने में कुछ समय बिताया। Node.js संस्करण को ब्राउज़रीकृत करने का प्रयास करने के बजाय, package.json में ब्राउज़र संस्करण इसका अपना प्रवेश बिंदु है।

तो, हां, bent में अब ब्राउज़र समर्थन है और यह काफी अच्छा है:

• शून्य निर्भरता या पॉलीफ़िल (पूरी तरह से लाने और ऐरेबफ़र पर बनाया गया है, इसलिए कोई बफर या स्ट्रीम पॉलीफ़िल नहीं है और बंडल करने के लिए कोई विवरण नहीं है)
• ~ 2K वेबपैक बंडल अन-मिनिफाइड या gzipped (किसी को मुझे बताना चाहिए कि यह उनके पसंदीदा मिनीफायर और कंप्रेशर्स के बाद क्या है)।
• सभी परीक्षण हेडलेस क्रोम में पास हो रहे हैं, जिसमें Node.js संस्करण में 100% कवरेज है (अभी भी स्वचालित ब्राउज़र कवरेज परीक्षण करने का एक शानदार तरीका नहीं है)

यह बहुत अच्छा है @ माइकेल

@csantanapr धन्यवाद! :)

axios आपकी नोड सेवा को क्रैश कर सकता है: https://github.com/axios/axios/issues/1804

मेरे लिए, शीर्ष चिंताएं हैं:

• क्या यह मेरे कॉर्पोरेट वातावरण में न्यूनतम विन्यास के साथ काम करता है? (योगदान करने वाले कारक: कॉर्पोरेट प्रॉक्सी HTTP और HTTPS दोनों लक्ष्यों के लिए HTTP हैं, सभी प्रॉक्सी सभी प्रमाणपत्रों को सही तरीके से नहीं संभालते हैं, उसी तरह, ...)
  
  
  
  • इसने मुझे विशेष रूप से एक या एक साल पहले अनुरोध को बंद करने से रोक दिया।
  
  
• क्या यह स्ट्रीमिंग का समर्थन करता है, उन मामलों के लिए जहां मुझे प्रॉक्सी फ़ाइल अपलोड/डाउनलोड करने की आवश्यकता है?

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

संपादित करें: यीआआह बिल्कुल नहीं कह सकता कि मैं आपको वहां दोष देता हूं।

संपादित करें 2: मान लीजिए कि मैं node-libcurl पर एक नज़र डालेगा।

@joedski हां, प्रॉक्सी सामान अनुरोध के बाहर व्यापक रूप से समर्थित नहीं है। और टीबीएच, उस काम को करने और उसका समर्थन करने के लिए किए गए काम की मात्रा को देखते हुए, मुझे आश्चर्य नहीं है कि कोई भी इसे करना नहीं चाहता, मेरे सहित;) मैंने इसे एक बार किया है और मैं लिखने के लिए बिल्कुल कूद नहीं रहा हूं यह फिर से तुला ‍♀️ . के लिए

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

नन्हा-अनुरोध (>1mio साप्ताहिक डाउनलोड)

अनुरोध के लिए ड्रॉप-इन प्रतिस्थापन, लेकिन बहुत छोटा - और कम विकल्पों के साथ। हुड के तहत node-fetch उपयोग करता है। इसे वहां पॉप करें जहां आप request का उपयोग करेंगे।

node-fetch गलत तरीके से रिपोर्ट किया जा रहा है और केवल "ब्राउज़र" संस्करण की सूचना दी गई है (_Node.js_ सूची के बिंदु को हराकर)। ऐसा लगता है कि गलत तरीके से मापा गया है:

• https://unpkg.com/[email protected]/browser.js

इसके बजाय, इनमें से किसी एक को मापा जाना चाहिए:

• https://unpkg.com/[email protected]/lib/index.js
• https://unpkg.com/[email protected]/lib/index.mjs
• https://unpkg.com/[email protected]/lib/index.es.js

वे लगभग ~ 40kb . के आसपास हैं

unfetch भी गलत तरीके से रिपोर्ट किया गया है:

• होमपेज कहता है कि "नोड में उपयोग करें। जेएस को आइसोमोर्फिक-अनफेच द्वारा नियंत्रित किया जाता है", इसलिए इसे दोनों के संयोजन की रिपोर्ट करनी चाहिए।
• isomorphic-unfetch Node.js के लिए नोड-फ़ेच ( कोड , डॉक्स ) का उपयोग करता है, इसलिए इसकी रिपोर्ट का आकार कम से कम नोड-फ़ेच (मेरी पिछली टिप्पणी देखें) होना चाहिए।

चूंकि इसे इतना बड़ा किया गया है, इसलिए मुझे node-fetch के साथ अपने अनुभव के बारे में कुछ कहना चाहिए।

सबसे पहले, यह काफी उपलब्धि है। इसमें जितना कोड और इंजीनियरिंग प्रयास किया गया है, वह हमारे द्वारा कभी भी अनुरोध किए जाने की तुलना में बहुत अधिक है। fetch एक छोटे एपीआई की तरह लगता है और मुझे लगता है कि लोग मानते हैं कि नोड.जेएस में एक संगत एपीआई प्रदान करने का प्रयास नाममात्र है, लेकिन यह वास्तव में नहीं है।

नतीजतन, कोड आधार बड़े पैमाने पर है। यह Node.js में एक बड़ी निर्भरता है, जिसे आप ब्राउज़र बंडलों में बिल्कुल नहीं देख पाएंगे, लेकिन ऐसा नहीं है कि Node.js में निर्भरता आकार कोई समस्या नहीं है, खासकर सर्वर रहित वातावरण में।

node-fetch परीक्षण करते समय अपरिहार्य है क्योंकि यह ब्राउज़र के एपीआई को पूरी तरह से अनुकरण करने का सभी काम करता है, लेकिन यदि आप इसे किसी एप्लिकेशन में उपयोग कर रहे हैं, यहां तक ​​​​कि एक जो Node.js और ब्राउज़र में चलाया जा रहा है, तो यह है इसके लायक होने के लिए बस बहुत अधिक कोड और बहुत अधिक संकेत।

IMO, इस समय एक पुस्तकालय के लिए सही दृष्टिकोण जो Node.js और ब्राउज़र दोनों में एक http क्लाइंट बनना चाहता है, ब्राउज़र में fetch और require(‘http’) का उपयोग करके विभाजित कार्यान्वयन के साथ एक समान API लागू करना है। fetch या require(‘http’) को लक्षित नहीं करना चाहिए और इन एपीआई के किसी भी तरफ अनुकरण करने पर भरोसा नहीं करना चाहिए। यह वास्तव में आपके विचार से बहुत आसान है, जैसा कि आप bent के कार्यान्वयन में देख सकते हैं जो अविश्वसनीय रूप से छोटा है https://github.com/mikeal/bent/tree/master/src

@mikeal मुझे एक कठिन समय चुकता हो रहा है

नतीजतन, कोड आधार बड़े पैमाने पर है। यह Node.js में एक बड़ी निर्भरता है, जिसे आप ब्राउज़र बंडलों में बिल्कुल नहीं देख पाएंगे, लेकिन ऐसा नहीं है कि Node.js में निर्भरता आकार कोई समस्या नहीं है, खासकर सर्वर रहित वातावरण में।

OP में सूचीबद्ध 0.4 kB बंडल आकार के साथ, जो दिए गए सभी विकल्पों में सबसे छोटा है?

@ डोमेनिक ब्राउज़र एपीआई को अनुकरण करने की जटिलता मुख्य समस्या है, डीबग करने का प्रयास करते समय यह बहुत अनावश्यक कोड और संकेत है। आपको Blob API मिल गया है, आपके पास body के लिए बहुत सारी मार्शलिंग है, आपके पास header marshalling की लगभग 400 लाइनें हैं, और यह भी नहीं देख रहा है वास्तविक एपीआई जो उजागर हो जाती है।

जैसा कि मैंने कहा, यह प्रभावशाली है, लेकिन यदि आप fetch API का अनुकरण करने के अलावा कुछ भी करना चाहते हैं तो यह केवल एक टन का संक्षिप्त, चतुर और अंततः अनावश्यक कोड है।

@ मिकेल आपने यह भी उल्लेख नहीं किया कि नोड-फ़ेच के लिए एक टन अधिक कोड की आवश्यकता है जो कि फ़ेच एपीआई के साथ 100% संगत हो: यह व्हाट-डब्ल्यूजी से पठनीय और लिखने योग्य धाराओं का समर्थन नहीं करता है (कुछ ऐसा जो आपको वातावरण का अनुकरण करते समय चाहिए) क्लाउडफ्लेयर वर्कर्स की तरह।

हम्म, मुझे अभी भी समझ में नहीं आया कि "0.4 kB, टेबल पर हर दूसरी प्रविष्टि से कम और तुला के आकार के 0.25x से कम" के साथ "अंततः अनावश्यक" कोड के "एक टन" को कैसे वर्गाकार किया जाए (जो माना जाता है कि "सही है" दृष्टिकोण" और "अविश्वसनीय रूप से छोटा")।

@domenic क्या आप ब्राउज़र बंडल आकार की तुलना कर रहे हैं? मैं Node.js में इन्हें डीबग करने की जटिलता के बारे में बात कर रहा हूँ। ब्राउज़र में मुझे उम्मीद है कि अधिकांश node-fetch कोड मौजूद नहीं होंगे, इसलिए मैं वास्तव में समझ नहीं पा रहा हूं कि आप क्या तुलना कर रहे हैं।

मैं ओपी में मूल्य की तुलना कर रहा हूं; मुझे यकीन नहीं है कि इसे कैसे मापा जाता है। शायद इसे सही तरीके से नहीं मापा जाता है, जिसके साथ ओपी को अपडेट करना अच्छी जानकारी होगी!

@domenic आह हाँ, वे सभी ब्राउज़र बंडल आकार हैं, और चूंकि पोस्ट बहुत पुरानी है, उनमें से कई पुराने हो सकते हैं, हालांकि bent आंकड़ा अभी भी काफी करीब है।

@ रूट/अनुरोध - 500 एलओसी में लिखा गया 80/20 ड्रॉप-इन प्रतिस्थापन, और शून्य निर्भरता:

अनुरोध.जेएस के व्यवहार के खिलाफ बनाया और परीक्षण किया गया, उद्देश्य पर।

https://git.rootprojects.org/root/request.js

हेलो सब लोग! मैं अपनी परियोजनाओं के लिए अनुरोध के योग्य प्रतिस्थापन खोजने के लिए थोड़ा सा शोध कर रहा हूं। अभी के लिए, मैंने इसे एक साथ रखा है: https://github.com/emanuelcasco/http-packages-benchmark

सिफारिशों और राय का निश्चित रूप से स्वागत है!

s request अब आधिकारिक रूप से बहिष्कृत कर दिया गया है, मैं request के लिए सुविधा-पूर्ण ड्रॉप-इन प्रतिस्थापन के रूप में आधिकारिक तौर पर $# request postman-request प्रस्तावित करने के महत्व पर अधिक जोर नहीं दे सकता, और संभवतः @root/request उन लोगों के लिए जिन्हें केवल request के सीमित उपसमुच्चय की आवश्यकता है और उदाहरण की परवाह नहीं करते हैं। धाराएँ

यह किसी भी पैकेज अनुरक्षक को request को छोड़ने और इस मुद्दे पर कुछ मिनटों से अधिक समय खर्च किए बिना, और अपनी पूरी लाइब्रेरी या ऐप को रिफलेक्टर किए बिना कष्टप्रद बहिष्करण संदेश से छुटकारा पाने की अनुमति देता है। मुझे यह पता लगाने में काफी समय और निराशा लगी कि इस तरह के ड्रॉप-इन प्रतिस्थापन मौजूद हैं।

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

मैं वास्तव में, वास्तव में इससे नफरत करता हूं जब "बहिष्करण" का उपयोग केवल "समर्थन के अंत" या "रखरखाव के अंत" को चिह्नित करने के लिए किया जाता है, जैसा कि यहां मामला प्रतीत होता है। लेकिन अगर आधिकारिक तौर पर समर्थित और सक्रिय रूप से बनाए रखा सुविधा-पूर्ण ड्रॉप-इन प्रतिस्थापन जैसे postman-request होता तो मुझे इसे खरीदने में बहुत कम परेशानी होती।

वास्तव में, क्या किसी ने इस पैकेज का रखरखाव डाकिया टीम को सौंपने पर विचार किया है? request को पदावनत करने के बजाय, क्यों न उन्हें postman-request से request पोर्ट करने का प्रस्ताव दिया जाए और उन्हें नए आधिकारिक अनुरक्षक बनने दिया जाए?

यहां मेरी अपनी छोटी लाइब्रेरी को बढ़ावा देने के लिए खेद है

केवल नोडज में उपयोग के लिए डिज़ाइन किया गया

const http = require('@zhangfuxing/http');
const assert = require('assert');

(async () => {
  // http
  const httpRes = await http.get('http://baidu.com');
  assert(httpRes.includes('<html>'));

  // https
  const httpsRes = await http.get('https://cnodejs.org/api/v1/topics?limit=1&mdrender=false');
  assert(httpsRes.success === true);

  // download file: use pipe
  const fs = require('fs');
  const res = await http.get('http://localhost:3000', {
    responseType: "stream"
  })
  res.pipe(require('fs').createWriteStream('zfx.txt'))
  // or use pipeline
  const stream = require('stream');
  const util = require('util');
  const pipeline = util.promisify(stream.pipeline);
  const res = await http.get(`${url}/stream`, {
    responseType: "stream"
  });
  await pipeline(res, fs.createWriteStream('zfx.txt'));

  // post Buffer
  const res = await http.post('http://localhost/upload', Buffer.from('abc'));
  assert(res.success === true);

  // post Stream
  const fs = require('fs');
  const readStream = fs.createReadStream('./index.js');
  const res = await http.post('http://localhost/upload', readStream);
  assert(res.success === true);

  // post json
  const data = {
    username: 'zfx',
    password: 'password'
  };
  const res = await http.post('http://localhost/upload', data);
  assert(res.success === true);

  // post application/x-www-form-urlencoded
  const data = {
    username: 'zfx',
    password: 'password'
  };
  const options = {
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded'
    }
  };
  const res = await http.post('http://localhost/upload', data, options);
  assert(res.success === true);

  // post FormData
  const FormData = require('form-data');
  const form = new FormData();
  const fs = require('fs');
  const readStream = fs.createReadStream('./index.js');
  form.append('my_field', 'my value');
  form.append('my_buffer', Buffer.from('abc'));
  form.append('my_file', readStream);
  // Set filename by providing a string for options
  form.append('my_file', readStream, '1.js' );
  // provide an object.
  form.append('my_file', readStream, { 
    filename: 'bar.jpg', 
    contentType: 'image/jpeg', 
    knownLength: 19806
  });
  const formHeaders = form.getHeaders();
  const res = await http.post('http://localhost/upload', form, {
    headers: {
      ...formHeaders,
    },
  });
  assert(res.success === true);

  // head
  const res = await http.head(url);
  assert(res.statusCode === 200);
  assert(res.statusMessage === 'OK');
  assert(res.headers && typeof res.headers === 'object');
  assert(res.statusCode === 200);
  assert(res.data === '');

  // options
  const res = await http.options(url);
  assert(res === 'GET,HEAD,POST,PUT,PATCH,DELETE'); 
})().catch(console.error);

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

इनमें से कोई भी http2 का समर्थन करता है?

@sakalys got में प्रयोगात्मक HTTP2 समर्थन है, जो अगले प्रमुख रिलीज (जल्द ही बाहर) में अंतर्निहित और स्थिर होगा।

प्रतिस्थापन में निकट गिरावट?

https://github.com/googleapis/teeny-request

इस पुस्तकालय को बहिष्कृत होते देखकर वास्तव में दुख हुआ। मुझे axios पसंद है, लेकिन कुछ उद्देश्यों के लिए, अनुरोध मेरी मुट्ठी पसंद था।

इनमें से कोई भी समर्थन अनुरोध समय? पहले बाइट, नेटवर्क लैग वगैरह के समय की तरह?
मैं एक परियोजना के लिए अनुरोध पुस्तकालय का उपयोग कर रहा हूं और इसके लिए समय महत्वपूर्ण है।

Google gaxios प्रदान करता है https://github.com/googleapis/gaxios - axios api over node-fetch

हमारे पास got रीडमी में got , request , node-fetch , axios , और superagent के बीच एक अच्छी तुलना है : https://github.com/sindresorhus/got#comparison
_(यदि आप कोई त्रुटि देखते हैं तो पीआर का स्वागत है। हमने इसे यथासंभव तटस्थ रखने की कोशिश की है)_

request से आगे बढ़ने के लिए गॉट के पास माइग्रेशन गाइड भी है: https://github.com/sindresorhus/got/blob/master/migration-guides.md

request से स्थानांतरित करने के लिए Got's माइग्रेशन मार्गदर्शिका को _move_ कर दिया गया है:
https://github.com/sindresorhus/got/blob/master/documentation/migration-guides.md

क्या मैं डाकिया-अनुरोध जोड़ने का सुझाव दे सकता हूं? मैं इसे अपने अगले प्रोजेक्ट पर आज़माउंगा। वैसे भी, दस्तावेज़ीकरण पर इसके बारे में यही कहा जाता है ...

यह उत्कृष्ट अनुरोध मॉड्यूल का एक कांटा है, जिसका उपयोग पोस्टमैन रनटाइम के अंदर किया जाता है। इसमें कुछ बगफिक्स हैं जो अनुरोध में तय नहीं हैं।

Redaxios देशी लाने के लिए 800 बाइट की तरह है https://github.com/developit/redaxios

भगवान !! मैं 3 घंटे से यह पता लगा रहा था कि बार-बार अपना कोड चेक किया। और इसने मुझे 404 त्रुटि दी, मैं निराश था। बहुत - बहुत धन्यवाद। मुझे लगता है कि मैं Fetch के साथ जाऊंगा।

https://www.npmjs.com/package/teeny-request एक अन्य विकल्प है, जिसका उपयोग Google API द्वारा किया जाता है।

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

क्या बेहतर होगा node-fetch या requests का फोर्कड संस्करण जो अब पोस्टमैन द्वारा बनाए रखा जाता है। मैंने अभी-अभी अपनी नोड यात्रा शुरू की है, इसलिए कुछ आसान की आवश्यकता है।

Axios का टाइमआउट कभी भी निश्चित नहीं होता है👎🏿

मुझे यहां फिन न देखकर बहुत आश्चर्य हुआ।

https://github.com/ethanent/phin

कैसे के बारे में url-request ?

https://github.com/Debdut/Url

कैसे के बारे में url-request ?

https://github.com/Debdut/Url

अभी भी थोड़ा युवा (1 दिन!)

@cjk प्रतिक्रिया के लिए धन्यवाद, आपको कौन सी सुविधाएँ पसंद आएंगी? यदि आप अधिक विशिष्ट हो सकते हैं।

त्वरित क्यू। देशी नोडज http के बजाय इन पुस्तकालयों का उपयोग करने का क्या फायदा है?

@cgarrovillo छोटा कोड => अधिक प्रभाव

यूआरएल-अनुरोध का प्रयास करें, बस फीचर सेट और संभावनाओं को देखें

@cjk प्रतिक्रिया के लिए धन्यवाद, आपको कौन सी सुविधाएँ पसंद आएंगी? यदि आप अधिक विशिष्ट हो सकते हैं।

@Debdut मैं सुविधाओं के बारे में सोच रहा हूँ जैसे:

1. प्रमाणीकरण
2. HTTP2
3. प्रॉक्सी-समर्थन
4. दबाव
5. टाइमआउट हैंडलिंग
6. कस्टम हुक
7. अनुरोध रद्द किया गया

url-request के दस्तावेज़ों से यह स्पष्ट नहीं है कि उनमें से कौन सा समर्थित है और कैसे।

हालाँकि, मुझे आपके द्वारा प्रदान किए गए कई उदाहरण पसंद आए!

बस अनुरोध का उपयोग तब तक करते रहें जब तक कि यह काम करना बंद न कर दे।

कोणीय में rxjs और नमूदार उत्कृष्ट हैं

किसी भी lib में कुकी जार अनुरोध की तरह है?

परीक्षण नोड लाल के साथ HTTP पुस्तकालय मिला। मैं

• एनपीएम स्थापित
• संदर्भ में जोड़ा गया
• अब प्रवाह संपादक में, मेरे जेएस फ़ंक्शन में _got_ आयात किया गया

परिणाम
HTTP अनुरोध करते समय ठीक काम करता है। (एकल परीक्षण किया)।
FAILS HTTPS रिक्वेस्ट करते समय। मुझे मिला :
RequestError: connect ECONNREFUSED 127.0.0.1:443

पहले तो मुझे लगा कि यह नोड-रेड एनवी से संबंधित कुछ है। बाद में पाया गया कि यह रेपो में एक खुला मुद्दा है : https://github.com/sindresorhus/got/issues/1414। मैं
और मेरी राय में, इसके बजाय _axios_ के लिए जाने का पर्याप्त कारण है। मैं
सिर्फ़ इतना चाहता था कि आप इसे जानो।

@damdauvaotran किसी भी lib में अनुरोध की तरह कुकी जार है?

देखें get.js, माइग्रेशन गाइड ।

gaxios का उल्लेख क्यों नहीं किया गया है?

एफडब्ल्यूआईडब्ल्यू, यहां एक एनपीएम ट्रेंड लिंक है जो शीर्ष पर उल्लिखित सभी परियोजनाओं की तुलना करता है। हालांकि यह निर्णय में शामिल एकमात्र कारक नहीं है, हमारे लिए और अधिकांश परियोजनाओं पर लोकप्रियता काफी महत्वपूर्ण है।
इस लेखन के समय, node-fetch सबसे लोकप्रिय विकल्प है।

दिलचस्प @ericsnap ... node-fetch और axios लोकप्रियता में क्रमशः पहले और तीसरे (लगभग दूसरे) हैं।

और मैं निम्नलिखित स्ट्रैपलाइन को gaxios डॉक्स से नोट करता हूं:

एक HTTP अनुरोध क्लाइंट जो नोड-फ़ेच के शीर्ष पर एक अक्ष जैसा इंटरफ़ेस प्रदान करता है

तो gaxios दो सबसे लोकप्रिय पुस्तकालयों को जोड़ती है। मैं gaxios में परिवर्तित हो रहा हूं और इसका उपयोग करना बहुत मजेदार है।

नोड-लाने / अक्ष

https://www.npmtrends.com/node-fetch-vs-got-vs-axios-vs-superagent

वर्तमान अनुरोध विकल्पों के एक समूह की समीक्षा करने के बाद, मैंने @sindresorhus को प्राप्त करने का संकल्प लिया है। मुझे एपीआई के अभ्यस्त होने में लगभग एक दिन का समय लगा (दस्तावेज़ काफी अच्छे रहे हैं)। मैंने extend के कारण एलओसी में एक महत्वपूर्ण कमी का अनुभव किया है और एक ही स्थान पर इतना सेट अप किया है, फिर कॉल जगहें और त्रुटि प्रबंधन आमतौर पर केवल कुछ मुट्ठी भर एलओसी हैं। यह अनुरोध, अनुरोध-वादा, अनुरोध-वादा-देशी नृत्य की तुलना में बहुत अधिक चिकना लगता है। एक बेहतरीन फीचर-सेट भी। बढ़िया काम और बहुत-बहुत धन्यवाद @sindresorhus!

मैं प्रवासन की प्रतीक्षा नहीं कर रहा था, लेकिन अब मैं बहुत साफ-सुथरा महसूस कर रहा हूं।