Node.js'nin ne zaman kullanılacağına nasıl karar verilir?


2195

Bu tür şeyler için yeniyim, ama son zamanlarda Node.js'nin ne kadar iyi olduğu hakkında çok şey duyuyorum . Genel olarak jQuery ve JavaScript ile çalışmayı ne kadar çok sevdiğimi göz önünde bulundurarak, Node.js'nin ne zaman kullanılacağına nasıl karar vereceğimi merak edemiyorum. Aklımdaki web uygulaması Bitly gibi bir şey - bazı içerikleri alıyor, arşivliyor .

Son birkaç gündür yaptığım tüm ödevlerden aşağıdaki bilgileri aldım. node.js

  • normal bir web sunucusu olarak çalıştırılabilen ve JavaScript programlarının çalıştırılabilmesini sağlayan bir komut satırı aracıdır
  • harika V8 JavaScript motorunu kullanıyor
  • aynı anda birkaç şey yapmanız gerektiğinde çok iyidir
  • olay tabanlı yani tüm harika Ajax benzeri şeyler sunucu tarafında yapılabilir
  • tarayıcı ve arka uç arasında kod paylaşmamıza izin verin
  • MySQL ile konuşalım

Karşılaştığım kaynaklardan bazıları:

Node.js'nin Amazon'un EC2 örneklerinde neredeyse kullanıma hazır olabileceğini göz önünde bulundurarak, PHP , Python ve Ruby gibi güçlü kralların aksine Node.js'yi gerektiren ne tür problemleri anlamaya çalışıyorum. . Bunun bir dil üzerinde sahip olduğu uzmanlığa bağlı olduğunu anlıyorum, ancak sorum daha genel kategoriye giriyor: Belirli bir çerçeveyi ne zaman kullanmalı ve özellikle ne tür problemler için uygundur?


4
Bu soru meta üzerinde tartışılmaktadır ( meta.stackoverflow.com/q/332386/497418 ).
zzzzBov

Yanıtlar:


1355

Node.js hakkında harika olanı özetlemek için harika bir iş yaptınız. Benim düşüncem, Node.js'nin özellikle tarayıcıdan sunucuya kalıcı bir bağlantı kurmak istediğiniz uygulamalar için uygun olduğudur. "Uzun yoklama" olarak bilinen bir teknik kullanarak kullanıcıya güncellemeleri gerçek zamanlı olarak gönderen bir uygulama yazabilirsiniz. Ruby on Rails veya Django gibi web devlerinin çoğunda uzun yoklama yapmak sunucuda çok büyük bir yük oluşturur çünkü her etkin istemci bir sunucu işlemini yiyor. Bu durum bir tarpit anlamına geliyor saldırısı demektir. Node.js gibi bir şey kullandığınızda, sunucunun her açık bağlantı için ayrı iş parçacığı tutmasına gerek yoktur.

Bu, tarayıcı tabanlı bir sohbet uygulaması oluşturabileceğiniz anlamına gelir , Node.js'de çok sayıda istemciye hizmet etmek için neredeyse hiç sistem kaynağı almayan . Bu tür uzun oylamayı yapmak istediğinizde Node.js harika bir seçenektir.

Ruby ve Python'un bu tür şeyleri yapmak için araçlara sahip olduklarından bahsetmeye değer ( sırasıyla olay makinesi ve bükülmüş ), ancak Node.js'nin bunu son derece iyi ve sıfırdan yapıyor. JavaScript, geri arama tabanlı bir eşzamanlılık modelinde son derece iyi bir konuma sahiptir ve burada mükemmeldir. Ayrıca, istemciye ve sunucuya özgü JSON ile serileştirme ve serileştirme yapabilmek oldukça şıktır.

Burada diğer cevapları okumak için sabırsızlanıyorum, bu harika bir soru.

Node.js'nin, istemci / sunucu boşluğunda çok fazla kodu yeniden kullanacağınız durumlar için de harika olduğunu belirtmek gerekir. Meteor çerçevesi gerçekten kolay bu yapar ve millet bir sürü bu web geliştirme geleceği olabileceğini öne için. Deneyimlerimden Meteor'da kod yazmanın çok eğlenceli olduğunu söyleyebilirim ve bunun büyük bir kısmı verilerinizi nasıl yeniden yapılandıracağınızı düşünmek için daha az zaman harcıyor, böylece tarayıcıda çalışan kod kolayca manipüle edin ve geri verin.

İşte piramit ve uzun oylama ile ilgili bir makale, bu da geventten biraz yardım alarak kurulumu çok kolay oldu: TicTacToe ve Piramit ile Uzun Yoklama .


12
Evet, bence 'node.js'nin tarayıcıdan sunucuya sürekli bağlantı gerektiren uygulamalar için özellikle uygun olduğunu düşünmek çok önemli. - sohbet programları veya etkileşimli oyunlar gibi 'Kullanıcı / sunucu iletişimine ihtiyaç duymayan bir uygulama oluşturuyorsa, diğer çerçevelerle geliştirme iyi olur ve çok daha az zaman alacaktır.
user482594

1
Bunun için teşekkürler ... Büyük Q ve A ;-) Ayrıca birkaç farklı olanlar üzerinde hem ön hem de arka uç gelişimi için bir büyük teknoloji hakim olmak açısından düşünürdüm;)
Stokedout

12
Neden uzun yoklama kullanıyorsunuz? Geleceğe ve prizlere ne oldu ?
hitautodestruct

1
Kısa cevabım arka plan sürecidir. İstek ve yanıt (dinlenme API'si dahil) diğer tüm diller ve sunucularla gerçekleştirilebilir. Yani web projelerini düğümde dönüştürmeyi düşünenler için. Tekrar düşünün aynı şey! Düğümü, imap ile e-posta okuma, görüntü işleme, dosyaları buluta yükleme veya çoğunlukla olay odaklı olan uzun veya hiç bitmeyen işlemler gibi arka plan işlemi olarak kullanın ...
Vikas

409

Node.js'nin gerçek zamanlı uygulamalar için en uygun olduğuna inanıyorum: çevrimiçi oyunlar, işbirliği araçları, sohbet odaları veya bir kullanıcının (veya robot? Veya sensörün?) Uygulamanın diğer kullanıcılar tarafından hemen görülmesi gereken herhangi bir şey, sayfa yenileme olmadan.

Socket.IO'nun Node.js ile birlikte, gerçek zamanlı gecikmenizi uzun yoklama ile mümkün olandan daha da azaltacağını da belirtmeliyim. Socket.IO, en kötü durum senaryosu olarak uzun sorgulamaya geri döner ve bunun yerine web soketlerini veya hatta varsa Flash'ı kullanır.

Ama aynı zamanda kodun iş parçacıkları nedeniyle bloke olabileceği hemen hemen her durumda Node.js ile daha iyi ele alınabileceğini de belirtmeliyim. Veya uygulamanın olay güdümlü olması gereken herhangi bir durum.

Ayrıca, Ryan Dahl bir konuşmada bir keresinde Node.js kriterlerinin normal eski HTTP istekleri için Nginx ile yakından rekabet ettiğini söyledi. Dolayısıyla, Node.js ile oluşturursak, normal kaynaklarımıza oldukça etkili bir şekilde hizmet edebiliriz ve etkinlik odaklı şeylere ihtiyaç duyduğumuzda, bu sorunla başa çıkmaya hazırız.

Artı her zaman JavaScript. Tüm yığın üzerinde Lingua Franca.


17
Sadece .Net ve Node arasında geçiş yapan bir kişinin gözlemi, Sistemin farklı alanları için farklı diller bağlam değiştirme yaparken çok yardımcı olur. Javascript'e baktığımda, İstemcide çalışıyorum, C #, App Server, SQL = veritabanı anlamına geliyor. Boyunca Javascript çalışarak, kendimi katmanları kafa karıştırıcı buldum ya da sadece bağlam anahtarına daha uzun sürdüm. Bu muhtemelen bütün gün .NET yığını ve gece Noding üzerinde çalışmanın bir eseridir, ancak bir fark yaratır.
Michael Blackburn

9
İlginç bir şekilde, ana akım ve yerel kültürler arasında geçiş yaparken lehçeleri değiştiren kültürler arası bireylerin uygulamasına "kod değiştirme" denir.
Michael Blackburn

1
Geçen gün, bir .jsşekilde farklı dosyalarıma nasıl farklı renkler atayabileceğimi düşünüyordum. İstemci tarafı için yeşil, sunucu tarafı için mavi. Kendimi “kaybolmaya” devam ediyorum.
AJB

209

NodeJS'i kullanma nedenleri:

  • Javascript çalıştırır, böylece sunucu ve istemcide aynı dili kullanabilir ve hatta aralarında bazı kodlar paylaşabilirsiniz (örneğin form doğrulaması için veya her iki uçta da görünüm oluşturmak için).

  • Tek dişli olay odaklı bir sistemdir hızlı geleneksel çok kanallı kıyasla kerede istekleri sürü tutarken bile, hem de basit bir Java veya ROR çerçeveler.

  • İstemci ve sunucu tarafı kitaplıkları / modülleri ve web geliştirme için komut satırı araçları da dahil olmak üzere NPM üzerinden erişilebilen ve sürekli büyüyen paket havuzu . Bunların çoğu, bazen bir sorunu bildirip saat içinde düzeltildiğini bulabileceğiniz github'da rahatça barındırılmaktadır! Standartlaştırılmış sorun bildirimi ve kolay çatalla her şeyin tek bir çatı altında olması güzel.

  • Javascript ile ilgili araçların ve görev koşucuları, küçültücüler, güzellik uzmanları, linters, ön işlemciler, paketleyiciler ve analitik işlemciler de dahil olmak üzere diğer web ile ilgili araçların çalıştırıldığı standart bir ortam haline gelmiştir .

  • Prototipleme, çevik geliştirme ve hızlı ürün yinelemesi için oldukça uygun görünüyor .

Nedenleri değil kullanım NodeJS için:

  • Derleme zamanı türü denetimi olmayan Javascript'i çalıştırır. Büyük, karmaşık güvenlik açısından kritik sistemler veya farklı kuruluşlar arasındaki işbirliğini içeren projeler için, sözleşmeli arabirimleri teşvik eden ve statik tür denetimi sağlayan bir dil , uzun vadede hata ayıklama süresinden (ve patlamalarından ) tasarruf edebilir . (JVM takılı kalsa da null, nükleer reaktörleriniz için lütfen Haskell kullanın.)

  • Buna ek olarak, NPM'deki paketlerin çoğu biraz ham ve hala hızlı bir şekilde geliştiriliyor. Daha eski çerçeveler için bazı kütüphaneler on yıllık bir test ve hata düzeltme sürecinden geçmiştir ve şimdiye kadar çok kararlıdır . Npmjs.org, paketleri derecelendirmek için bir mekanizmaya sahip değildir , bu da paketlerin aşağı yukarı aynı şeyi yapmasına neden olur ve bunun büyük bir yüzdesi artık korunmaz.

  • İç içe geri arama cehennemi. (Elbette bunun için 20 farklı çözüm var ...)

  • Sürekli büyüyen paket havuzu, bir NodeJS projesinin diğerinden radikal olarak farklı görünmesini sağlayabilir . Mevcut çok sayıda seçenek nedeniyle uygulamalarda büyük bir çeşitlilik vardır (örn. Express / Sails.js / Meteor / Derby ). Bu bazen yeni bir geliştiricinin bir Düğüm projesine atlamasını zorlaştırabilir. Bir Rails geliştiricisinin mevcut bir projeye katılmasının aksine : tüm Rails uygulamalarının benzer bir yapı kullanması teşvik edildiğinden uygulamaya hızlı bir şekilde aşina olmalıdır .

  • Dosyalarla uğraşmak biraz acı verebilir. Bir metin dosyasından satır okumak gibi diğer dillerde önemsiz şeyler, Node.js ile 80+ yukarı oylamada bir StackOverflow sorusu olduğu konusunda yeterince garip . Orada bir CSV dosyasından bir defada bir kaydı okumak için basit bir yolu . Vb.

NodeJS'i seviyorum, hızlı ve vahşi ve eğlenceli, ancak kanıtlanabilir doğrulukla çok az ilgisi olduğundan endişeliyim. Umarım sonunda her iki dünyanın en iyilerini birleştirebiliriz. Gelecekte Düğümün yerini alacakları görmek için sabırsızlanıyorum ...


1
@nane Evet Bu sorunu çözebileceklerini düşünüyorum, ancak daha sonra yalnızca typesafe dillerinde yazılmış kütüphaneleri kullanmakla sınırlamanız veya kod tabanınızın tümünün statik olarak yazılmadığını kabul etmeniz gerekir . Ancak bir argüman devam ediyor: dilden bağımsız olarak kodunuz için iyi testler yazmanız gerektiğinden , dinamik olarak yazılmış kod için bile güven seviyeniz eşit olmalıdır . Bu argümanı kabul edersek, güçlü yazmanın avantajları, geliştirme / hata ayıklama süresi, geçerlilik ve optimizasyona yardımcı olacak şekilde azaltılır .
joeytwiddle

1
@kervin, bazı kriterlerin harika olacağını kabul ediyorum, ancak çevrimiçi olarak ne bulabileceğimden hayal kırıklığına uğradım. Bazıları, .NET performansının Düğümlerle karşılaştırılabilir olduğunu, ancak gerçekte ne yaptığınızın çok önemli olduğunu savundu . Düğüm, birçok eşzamanlı bağlantı ile küçük mesajlar vermekte harika olabilir, ancak ağır matematiksel hesaplamalar için çok da iyi olmayabilir. İyi bir performans karşılaştırmasının çeşitli durumları test etmesi gerekir.
joeytwiddle

2
@joeytwiddle, daha büyük karmaşık programları ve statik daktilo işlemeyi ele alma konusunda Typescript Node.js'ye yardımcı olmaz mı?
CodeMonkey

2
@joeytwiddle, npm paketinin hala korunup korunmadığını belirlemek için stillmaintained.com'u kullanabilirsiniz (çoğunluk github'da olduğu için). Buna ek olarak, npm searchve npm showsize bir paketin son çıkış tarihini gösterecektir.
Dan Pantry

3
Rayları düğüm ile karşılaştırarak bir platformu bir çerçeveyle karıştırıyorsunuz. Rails, tıpkı Yelkenler ve meteor Javascript için çerçeveler gibi Ruby için bir çerçevedir.
BonsaiOak


127

Node.js kullandığım bir gerçek dünya örneğim var. Çalıştığım şirket, basit bir statik HTML web sitesine sahip olmak isteyen bir müşteri aldı. Bu web sitesi PayPal kullanarak bir ürün satmak içindir ve müşteri satılan ürünlerin miktarını gösteren bir sayaca sahip olmak istemiştir. Müşterinin bu web sitesini çok fazla ziyaret etmesi bekleniyor. Sayacı Node.js ve Express.js çerçevesini kullanarak yapmaya karar verdim .

Node.js uygulaması basitti. Satılan ürün miktarını bir Redis veritabanından alın, ürün satıldığında sayacı artırın ve API aracılığıyla kullanıcılara sayaç değerini sunun .

Bu durumda Node.js kullanmayı tercih etmemin bazı nedenleri

  1. Çok hafif ve hızlı. Bu web sitesinde üç hafta içinde 200000'den fazla ziyaret yapıldı ve en az sayıda sunucu kaynağı her şeyi halledebildi.
  2. Sayacın gerçek zamanlı olması gerçekten kolaydır.
  3. Node.js'yi yapılandırmak kolaydı.
  4. Ücretsiz olarak birçok modül mevcuttur. Örneğin, PayPal için bir Node.js modülü buldum.

Bu durumda, Node.js harika bir seçimdi.


7
Böyle bir şeyi nasıl barındırıyorsunuz? O zaman üretim sunucusunda nodejs kurmanız gerekiyor mu? Linux'ta mı?
Miguel Stevens

1
Nodejitsu ve Heroku gibi birkaç PaaS var. Ya da bir linux kutusuna nodejs kurabilirsiniz, örneğin amazon ec2. bkz: lauradhamilton.com/…
harry young

13
1.814.400 saniye içinde 200.000 ziyaret. Hiç alakalı değil. Hatta bash bile en yavaş sunucuda bu kadar çok istekte bulunabilir. Kazı kazan sunucusu. En yavaş VM.
Tiberiu-Ionuț Stan

105

Düğüm kullanarak bir sonraki projenize başlamanın en önemli nedenleri ...

  • Tüm havalı adamlar onun içinde ... bu yüzden eğlenceli olmalı .
  • Soğutucuda Hangout yapabilir ve övünmek için çok sayıda Düğüm macerasına sahip olabilirsiniz.
  • Bulut barındırma maliyetleri söz konusu olduğunda bir kuruş pinchersınız.
  • Rails ile bunu yaptın mı
  • IIS dağıtımlarından nefret ediyorsunuz
  • Eski BT işiniz oldukça matlaşıyor ve yeni ve parlak bir Başlangıçta olmanızı dilerim.

Ne bekleyebileceğinizi ...

  • Asla ihtiyaç duymadığınız tüm sunucu bloatware olmadan Express ile kendinizi güvende hissedeceksiniz.
  • Bir roket gibi çalışır ve iyi ölçeklenir.
  • Hayal ediyorsun. Yüklediniz. Düğüm paketi repo npmjs.org , dünyadaki en büyük açık kaynak kütüphanesi ekosistemidir.
  • Beyniniz, iç içe geçmiş geri aramalar diyarında çarpılacak ...
  • ... sözlerini tutmayı öğrenene kadar .
  • Sequelize ve Pasaport yeni API arkadaşlarınızdır.
  • Hata ayıklama çoğunlukla zaman uyumsuz kod umm alacak ... ilginç .
  • Tüm Noders zamanı master typescript .

Kim kullanıyor?

  • PayPal, Netflix, Walmart, LinkedIn, Groupon, Uber, GoDaddy, Dow Jones
  • İşte bu yüzden Düğüm'e geçtiler .

18
Evet, bu soruya geleneksel şekilde cevap verebilirdim. Sanırım bunu yapmaya hak kazandım ama çoğu zaten söylendi ve hafif yürekli eğlencenin monotonluğu kıracağını düşündüm. Diğer sorulara düzenli olarak teknik cevaplar veriyorum.
Tony O'Hagan

1
eşzamansız kod için ES6 jeneratörleri kullanılarak iç içe geçmiş geri çağrılardan kaçınılabilir
refactor

1
@CleanCrispCode: Evet, gerçekten! ES6, C # stilini benimsedi async/ awaitartık geleneksel try/ destekleyen daha temiz asenkron Düğüm kodunu kullanıma sunabiliyoruz catch. 2016/17 JS kodlayıcıları ES6'ya geçiyor.
Tony O'Hagan

1
on binlerce kez "İhtiyacınız olmayan tüm sunucu bloatware olmadan Express ile kendinizi güvende hissedeceksiniz"
Simone Poggi

60

Silver Bullet gibi bir şey yok. Her şey onunla ilişkili bir maliyetle geliyor. Yağlı yiyecekler yerseniz, sağlığınızdan ödün verirsiniz ve sağlıklı yiyecekler yağlı yiyecekler gibi baharatlarla gelmez. Yiyeceklerinde olduğu gibi sağlık mı yoksa baharat mı istedikleri bireysel seçimdir. Aynı şekilde Node.js belirli senaryoda kullanılmayı düşünür. Uygulamanız bu senaryoya uymuyorsa, bunu uygulama geliştirme için dikkate almamalısınız. Ben sadece aynı düşüncemi koyuyorum:

Node.JS ne zaman kullanılır?

  1. Sunucu tarafı kodunuz çok az işlemci döngüsü gerektiriyorsa. Diğer dünyada engellemesiz işlem yapıyorsunuz ve çok fazla CPU döngüsü tüketen ağır algoritma / İş yok.
  2. Javascript arka zemindeyseniz ve istemci tarafı JS gibi Tek Dişli kod yazarken rahatsanız.

Node.JS kullanılmadığı zaman

  1. Sunucu isteğiniz, yoğun CPU tüketen algoritmaya / Job'a bağlıdır.

Node.JS ile Ölçeklenebilirlik Değerlendirmesi

  1. Node.JS'nin kendisi, temel sistemin tüm çekirdeğini kullanmaz ve varsayılan olarak tek iş parçacıklıdır, çok çekirdekli işlemciyi kullanmak ve çok iş parçacıklı hale getirmek için kendi başına mantık yazmanız gerekir.

Node.JS Alternatifleri

Düğüm.JS yerine kullanılabilecek başka bir seçenek daha var, ancak Vert.x oldukça umut verici görünüyor ve çokgen ve daha iyi ölçeklenebilirlik konuları gibi birçok ek özelliğe sahip.


24
"Sunucu tarafı isteğiniz," Ne zaman kullanılmaz "bölümünde listelenen" Dosya GÇ veya Soket GÇ gibi engelleme işlemlerini içeriyorsa "konusunda emin değilim. Anladığım doğru ise, node.js'nin güçlü yönlerinden biri, IO'yu engellemeden işlemek için güçlü asenkron araçlara sahip olmasıdır. Dolayısıyla Node.js, ES'yi engellemek için "bir tedavi" olarak görülebilir.
Ondrej Peterka

3
@OndraPeterka: Node.js'nin sunucu IO'yu engellemede haklısınız, ancak sunucudaki istek işleyiciniz başka bir web hizmeti / Dosya işlemine engelleme çağrısı yapıyorsa, Node.js burada yardımcı olmaz. Yalnızca sunucuya gelen istekler için engellenmez, ancak uygulama isteği işleyicinizden gelen istekler için değildir.
Ajay Tiwari

4
@ nodejs.org'dan "engellemeyen G / Ç" diyorlar, lütfen "Ne Zaman DEĞİL" 2 ve
3'lerinizi

5
Geçerli sürümde, düğüm aslında küme kullanarak çok çekirdekli desteği destekler. Bu, Düğüm uygulaması performansını gerçekten en az iki kez artırır. Bununla birlikte, performansın küme lib'ını sabitlediğinde iki kattan fazla olması gerektiğini düşünüyorum.
Nam Nguyen

4
Yoğun hesaplama için node.js'yi kullanabilirsiniz. Kullanın fork. Bkz. Stackoverflow.com/questions/9546225/… . Düğüm, clustermodülle çok sayıda çekirdeği çok iyi işler . nodejs.org/api/cluster.html
Jess

41

Hiç kimsenin Node.js hakkında bahsetmediğini düşündüğüm bir başka harika şey , şaşırtıcı topluluk, paket yönetim sistemi (npm) ve paketlerinize dahil ederek içerebileceğiniz modüllerin miktarıdır.


6
Ve bu paketlerin hepsi nispeten taze, bu yüzden gezinin avantajına sahipler ve son web standartlarına uyma eğilimi gösteriyorlar.
joeytwiddle

3
Tüm gerekli saygıyla, npm'de çok fazla paket korkunçtur, çünkü npm'nin paketleri derecelendirmek için bir mekanizması yoktur . CPAN'dan bir görüş var mı?
Dan Dascalescu

çok kötü websockets kütüphanelerinin hiçbiri rfc 6455 teknik özelliklerini karşılayamıyor. node.js fanboyları bu gerçek verildiğinde sağır, dilsiz ve kördür.
r3wt

1
Ne zaman yorum yaptığını bilmiyorum ama şu anda ws kütüphanesi bu spec destekliyor
Jonathan Gray

37

Benim parçam: nodejs, analitik, sohbet uygulamaları, apis, reklam sunucuları, vb. Gibi gerçek zamanlı sistemler yapmak için harikadır.

Düzenle

Nodejs kullanmaya başladığımdan bu yana birkaç yıl geçti ve statik dosya sunucuları, basit analizler, sohbet uygulamaları ve çok daha fazlasını içeren birçok farklı şey yapmak için kullandım. Nodejs ne zaman kullanılır

Ne zaman kullanılır?

Eşzamanlılık ve hıza vurgu yapan sistem yaparken.

  • Yalnızca sohbet uygulamaları, irc uygulamaları vb.
  • Coğrafi konum, video akışı, ses akışı vb.Gerçek zamanlı kaynaklara vurgu yapan sosyal ağlar.
  • Analitik web uygulaması gibi küçük veri parçalarını gerçekten hızlı bir şekilde işleme.
  • Bir REST sadece api.

Ne zaman kullanılmaz

Onun çok yönlü bir web sunucusu böylece istediğiniz yerde kullanabilirsiniz ama muhtemelen bu yerlerde.

  • Basit bloglar ve statik siteler.
  • Tıpkı statik bir dosya sunucusu gibi.

Unutmayın ki sadece zıplıyorum. Statik dosya sunucuları için, apache temelde daha iyi olduğu için daha iyidir. Nodejs topluluğu yıllar içinde daha büyük ve daha olgunlaşmıştır ve kendi hosting seçiminiz varsa nodejs'in hemen hemen her yerde kullanılabileceğini söylemek güvenlidir.


Basit bloglar yine de Node.js'den yararlanabilir. Statik dosyalar sunmak için Node.js'yi kullanmaya devam edebilirsiniz ve yük artarsa, mevcut en iyi uygulamalara göre Nginx ters proxy'sini ekleyin. Apache httpd sunucusu ölmekte olan bir dinozor - bu Netcraft anketine bakın .
Endrju

Başka türlü söyleyebilirim - ghost.org'a bir göz atın , harika görünüyor ve NodeJ'lerin üzerine inşa edilmiştir - işbirliği, gerçek zamanlı makale düzenleme. Ayrıca, sadejs.org kullanarak diyelim ki basit bir sayfa oluşturmak kolay, hızlıdır ve sunucu tarafı programlama dillerinden herhangi birini öğrenmekle uğraşmanıza gerek yoktur
Bery

30

Nerede kullanılabilir

  • Yüksek oranda olay güdümlü ve yoğun G / Ç bağlı uygulamalar
  • Diğer sistemlere çok sayıda bağlantıyı yöneten uygulamalar
  • Gerçek zamanlı uygulamalar (Node.js sıfırdan gerçek zamanlı ve kullanımı kolay olacak şekilde tasarlanmıştır.)
  • Diğer kaynaklara giden ve diğer kaynaklardan gelen bilgi yığınlarını dengeleyen uygulamalar
  • Yüksek trafik, ölçeklenebilir uygulamalar
  • Çok fazla veri analizi yapmak zorunda kalmadan platform API'sı ve veritabanıyla konuşmak zorunda olan mobil uygulamalar
  • Ağa bağlı uygulamalar oluşturun
  • Arka uçla çok sık konuşması gereken uygulamalar

Mobil cephede, prime time şirketleri mobil çözümleri için Node.js'ye güveniyorlar. Nedenini kontrol et?

LinkedIn tanınmış bir kullanıcıdır. Tüm mobil yığını Node.js üzerinde oluşturulmuştur. Her fiziksel makinede 15 örnekli 15 sunucu çalıştırmaktan, trafiği iki katına çıkarabilen sadece 4 örneğe geçtiler!

eBay , HTTP API'leri için web sorgu dili olan ql.io'yu başlattı ve çalışma zamanı yığını olarak Node.js'yi kullandı. Her bir bağlantı yaklaşık 2kB bellek tüketen, node.js işlemi başına 120.000'den fazla etkin bağlantıyı işlemek için geliştirici kalitesinde düzenli bir Ubuntu iş istasyonunu ayarlayabildiler!

Walmart , Node.js'yi kullanmak için mobil uygulamasını yeniden tasarladı ve JavaScript işlemlerini sunucuya aktardı.

Daha fazla bilgi için: http://www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/


20

Eşzamanlı istek işleme için en iyi düğüm -

Öyleyse bir hikaye ile başlayalım. Son 2 yıldan beri JavaScript üzerinde çalışıyorum ve web kullanıcı arabirimi geliştiriyorum ve bundan keyif alıyorum. Arka uç çocuklar bize Java, python (umursamıyoruz) ile yazılmış bazı API'ler sağlıyor ve sadece bir AJAX çağrısı yazıyoruz, verilerimizi alıyor ve ne olduğunu tahmin ediyoruz! İşimiz bitti. Ama gerçekte bu o kadar kolay değil, elde ettiğimiz veriler doğru değilse veya bazı sunucu hataları varsa, sıkışıp kaldık ve arka uç adamlarımızla posta veya sohbet yoluyla iletişime geçmeliyiz (bazen whatsApp'ta da :).) Bu serin değil. API'larımızı JavaScript'te yazıp bu API'ları kullanıcı arabirimimizden çağırırsak ne olur? Evet, bu çok güzel çünkü API'de herhangi bir sorunla karşılaşırsak içine bakabiliriz. Bil bakalım ne oldu ! bunu şimdi yapabilirsin, nasıl? - Düğüm senin için orada.

Tamam, API'nizi JavaScript'te yazabileceğinizi kabul ettim, ancak yukarıdaki sorunla ilgili sorunum yoksa ne olur? Dinlenme API'sı için düğümü kullanmak için başka bir nedeniniz var mı?

işte sihir başlıyor. Evet, API'larımız için düğümü kullanmak için başka nedenlerim var.

Engelleme işlemine veya iş parçacığına dayanan geleneksel dinlenme API sistemimize geri dönelim. İki eşzamanlı istek oluştuğunu varsayalım (r1 ve r2), her biri veritabanı işlemi gerektiriyor. Geleneksel sistemde ne olacak:

1. Bekleme Yolu: Sunucumuz r1istek sunmaya başlar ve sorgu yanıtını bekler. tamamlandıktan sonra r1, sunucu hizmet vermeye başlar r2ve bunu aynı şekilde yapar. Bu yüzden beklemek iyi bir fikir değil çünkü fazla vaktimiz yok.

2. iş parçacığı yolu: sunucumuz hem istekleri için iki iş parçacığı oluşturur r1ve r2veritabanı çok hızlı sorgulama sonra amacına hizmet. Ama bellek tüketir çünkü görebilirsiniz iki iş parçacığı da her iki istek aynı verileri sorgulama zaman sorun artar sonra kilitlenme tür sorunları ile uğraşmak zorunda. Yani beklemekten daha iyi ama yine de sorunlar var.

Şimdi, düğüm nasıl yapacak:

3. Düğüm: Düğümde aynı eşzamanlı istek geldiğinde, bir olayı geri çağırma ile kaydeder ve ilerler ve belirli bir istek için sorgu yanıtını beklemez . Yanir1 istek geldiğinde düğümün olay döngüsü (evet bu amaca hizmet eden düğümde.) bir olayı geri arama işleviyle kaydedin ve hizmet r2isteği için ilerleyin ve benzer şekilde etkinliğini geri aramasına kaydedin. Herhangi bir sorgu bittiğinde, ilgili olayı tetikler ve kesintiye uğramadan tamamlanma çağrısını yürütür.

Yani bekleme yok, iş parçacığı yok, bellek tüketimi yok - evet bu dinlenme API hizmet için düğüm.


1
Merhaba Anshul. Kilitlenmenin diş açma biçiminde nasıl meydana gelebileceğine ilişkin bir kaynak hazırlayabilir veya önerebilir misiniz?
jsbisht

16

Benim bir neden daha yeni bir proje için node.js seçmektir:

Saf bulut tabanlı geliştirme yapabilme

Ben kullandım Cloud9 IDE bir süre ve şimdi bunun tüm geliştirme yaşam döngülerini kapsar onsuz düşünemiyorum. Tek ihtiyacınız olan bir tarayıcıdır ve istediğiniz zaman istediğiniz cihazda kodlayabilirsiniz. Bir Bilgisayarda (evde olduğu gibi) kodu, ardından başka bir bilgisayarda (iş yerinde olduğu gibi) check-in yapmanız gerekmez.

Tabii ki, diğer diller veya platformlar için bulut tabanlı IDE olabilir (Cloud 9 IDE diğer diller için de destek ekliyor), ancak Node.js geliştirmesi için Cloud 9'u kullanmak benim için gerçekten harika bir deneyim.


1
Aslında Cloud9 IDE ve diğerleri (kullandığım kodlama) neredeyse tüm web dillerini destekler.
Wanny Miarelli

7
Ciddi misin dostum? bir yığın seçmek için kriterler nelerdir? :) mutlu senin için çalışıyor!
15'te matanster

15

Düğümün sağladığı bir şey daha, düğümün alt sürecini ( her biri dokümanlar için 10mb bellek gerektiren her bir childProcess.fork ()) kullanarak düğümün birden çok v8 örneğini oluşturma ve böylece sunucuyu çalıştıran ana işlemi etkilememektir. Bu nedenle, büyük sunucu yükü gerektiren bir arka plan işini boşaltmak çocuk oyuncağı haline gelir ve bunları gerektiğinde kolayca öldürebiliriz.

Düğümü çok kullanıyorum ve oluşturduğumuz uygulamaların çoğunda, aynı anda ağır bir ağ trafiği için sunucu bağlantılarına ihtiyaç duyuyorum. Express.js ve yeni Koajs (geri arama cehennemini kaldıran) gibi çerçeveler , düğüm üzerinde çalışmayı daha da kolaylaştırdı.


15

Asbest longjohns takılıyor ...

Dün başlığımı Packt Yayınları, JavaScript ile Reaktif Programlama . Gerçekten Node.js merkezli bir başlık değil; erken bölümler teoriyi ve daha sonra kod ağırlıklı bölümler uygulamayı kapsar. Gerçekten okuyuculara bir web sunucusu vermek için başarısız uygun olacağını düşünmüyordu çünkü node.js gibiydi farkla bariz bir seçim. Dava açılmadan önce kapatıldı.

Node.js ile yaşadığım deneyim hakkında çok pembe bir görünüm verebilirdim. Bunun yerine iyi puanlar ve karşılaştığım kötü noktalar konusunda dürüst oldum.

Burada alakalı birkaç alıntı ekleyeyim:

Uyarı: Node.js ve ekosistemi sıcak - sizi kötü bir şekilde yakacak kadar sıcak !

Matematikte öğretmen yardımcısı olduğumda, bana söylenen açık olmayan önerilerden biri, bir öğrenciye bir şeyin “kolay” olduğunu söylememekti. Nedeni geriye dönük olarak biraz açıktı: İnsanlara bir şeyin kolay olduğunu söylerseniz, bir çözüm görmeyen biri (daha da fazla) aptal hissedebilir, çünkü sadece sorunu nasıl çözeceklerini değil, sorunu da onlar anlamak için çok aptal kolay bir olduğunu!

Python / Django'dan gelen insanları rahatsız eden değil, bir şeyi değiştirirseniz kaynağı hemen yeniden yükleyen gotcha'lar var. Node.js ile varsayılan davranış, bir değişiklik yaparsanız, eski sürümün zaman sonuna kadar veya sunucuyu el ile durdurup yeniden başlatana kadar etkin olmaya devam etmesidir. Bu uygunsuz davranış sadece Pythonistas'ı kızdırmaz; çeşitli geçici çözümler sağlayan yerel Node.js kullanıcılarını da tahriş eder. StackOverflow sorusu “Node.js'deki dosyaları otomatik olarak yeniden yükle”, bu yazı yazıldığı sırada 200'den fazla upvote ve 19 cevaba sahip; bir düzenleme kullanıcıyı anasayfada bir dadı komut dosyasına, düğüm süpervizörüne yönlendirir http://tinyurl.com/reactjs-node-supervisor adresindeki. Bu sorun, yeni kullanıcıları aptal hissetmek için büyük bir fırsat verir, çünkü sorunu çözdüklerini düşündüler, ancak eski, buggy davranışı tamamen değişmedi. Ve sunucuyu zıplamayı unutmak kolaydır; Bunu defalarca yaptım. Ve vermek istediğim mesaj şudur: “Hayır, aptal değilsin çünkü Node.js'nin bu davranışı arkanı ısırdı; sadece Node.js tasarımcıları burada uygun davranış sağlamak için hiçbir neden görmediler. Bununla başa çıkmaya çalışın, belki düğüm süpervizöründen veya başka bir çözümden biraz yardım alın, ancak lütfen aptal olduğunuzu hissetmeyin. Problemi olan siz değilsiniz; sorun Node.js'nin varsayılan davranışında. ”

Bu bölüm, bazı tartışmalardan sonra, tam olarak “Bu kolay” izlenimi vermek istemediğim için bırakıldı. İşleri çalıştırırken ellerimi tekrar tekrar kestim ve zorlukları düzeltmek istemiyorum ve sizi Node.js ve ekosisteminin iyi işlev görmesinin basit bir mesele olduğuna ve sizin için de basit olmadığına inanmaya ayarlıyorum , ne yaptığını bilmiyorsun. Node.js kullanarak iğrenç zorluklarla karşılaşmazsanız, bu harika. Eğer yaparsan, “Aptalım - benden yanlış bir şey olmalı” hissini bırakıp gitmediğini umarım. Node.js ile ilgili kötü sürprizlerle karşılaşırsanız aptal değilsiniz. Sen değilsin! Bu Node.js ve ekosistemi!

Son bölümlerde ve sonuçta yükselen kreşendodan sonra gerçekten istemediğim Ek, ekosistemde neler bulabildiğimi anlatıyor ve moronik değişmezlik için bir çözüm sağladı:

Mükemmel bir uyum gibi görünen ve yine de kullanılabilen başka bir veritabanı, HTML5 anahtar / değer deposunun sunucu tarafı uygulamasıdır. Bu yaklaşım, en iyi ön uç geliştiricilerin yeterince iyi anladıkları bir API'nın temel avantajına sahiptir. Bu nedenle, aynı zamanda iyi olmayan ön uç geliştiricilerin yeterince iyi anladıkları bir API. Ancak düğüm-localstorage paketi ile, sözlük-sözdizimi erişimi sunulmazken (localStorage.setItem (anahtar, değer) veya localStorage [s] yerine localStorage.getItem (anahtar) kullanmak istersiniz), tam localStorage semantiği uygulanır , varsayılan 5 MB'lık bir kota dahil - NEDEN?Sunucu tarafı JavaScript geliştiricilerinin kendilerinden korunması gerekiyor mu?

İstemci tarafı veritabanı yetenekleri için, web sitesi başına 5 MB'lık bir kota, geliştiricilerin onunla çalışmasına izin vermek için gerçekten cömert ve kullanışlı bir solunum odasıdır. Çok daha düşük bir kota belirleyebilir ve geliştiricilere çerez yönetimi ile birlikte topallama üzerinde ölçülemez bir gelişme sunabilirsiniz. 5 MB'lık bir sınır, Big Data istemci tarafı işlemeye çok hızlı bir şekilde borç vermez, ancak becerikli geliştiricilerin çok şey yapmak için kullanabileceği oldukça cömert bir ödenek vardır. Ancak öte yandan, 5MB yakın zamanda satın alınan çoğu diskin özellikle büyük bir kısmı değildir, yani siz ve bir web sitesi disk alanının makul kullanımının ne olduğu konusunda anlaşmazsanız veya bazı siteler gerçekten hoggish ise, çok fazla ve sabit sürücünüz zaten çok dolu olmadığı sürece batak bir sabit sürücü tehlikesi yok.

Ancak, sunucunuz için tek bir kod yazarken, veritabanınızı kabul edilebilir 5 MB'den daha fazla yapmak için herhangi bir ek korumaya ihtiyacınız olmadığına dikkatlice işaret edebilirsiniz. Çoğu geliştirici, dadı gibi davranan ve 5MB'den fazla sunucu tarafı veri depolamasına karşı koruyan araçlara ne ihtiyaç duymaz ne de istemez. Ve istemci tarafında altın dengeleme eylemi olan 5MB kota, Node.js sunucusunda biraz aptalca. (Ve bu Ek'te kapsanan gibi birden fazla kullanıcı için bir veritabanı için, her kullanıcı hesabı için diskte ayrı bir veritabanı oluşturmadıkça, kullanıcı hesabı başına 5MB olmadığını, biraz acı verici bir şekilde belirtilebilir; tüm kullanıcı hesaplarını bir araya getirir. acıviral giderseniz!) Belgeler kotanın özelleştirilebilir olduğunu, ancak bir hafta önce geliştiriciye kotanın nasıl değiştirileceğini soran bir e-postanın yanı sıra, StackOverflow sorusu da aynı şekilde sorulduğunu belirtir. Bulabildiğim tek cevap, bir kurucuya isteğe bağlı ikinci tamsayı argümanı olarak listelendiği Github CoffeeScript kaynağında. Bu kadar kolay ve bir disk veya bölüm boyutuna eşit bir kota belirtebilirsiniz. Ancak, mantıklı olmayan bir özelliği taşımanın yanı sıra, aracın yazarı, 0'ın bir değişkenin veya fonksiyonun bir kaynak için maksimum sınır belirteceği bir değişken için “sınırsız” anlamına gelen çok standart bir kuralı takip etmeyi tamamen başaramamıştır. Bu yanlış özellikle yapılacak en iyi şey muhtemelen kotanın Infinity olduğunu belirtmektir:

if (typeof localStorage === 'undefined' || localStorage === null)
  {      
  var LocalStorage = require('node-localstorage').LocalStorage;
  localStorage = new LocalStorage(__dirname + '/localStorage',
    Infinity);
  }

İki yorumun sırayla değiştirilmesi:

İnsanlar gereksiz yere sürekli olarak JavaScript'i bir bütün olarak kullanarak kendilerini vurdular ve JavaScript'in saygın bir dil haline getirilmesinin bir kısmı, bir dil olarak Douglas Crockford, “Bir dil olarak JavaScript'in gerçekten iyi kısımları ve gerçekten kötü kısımları var. İşte iyi bölümler. Sadece başka bir şey olduğunu unut. ” Belki de sıcak Node.js ekosistemi kendi “Douglas Crockford” u yetiştirecek, “Node.js ekosistemi bir kodlama Vahşi Batı'dır, ancak bulunacak bazı gerçek taşlar vardır. İşte bir yol haritası. Neredeyse her ne pahasına olursa olsun kaçınılması gereken alanlar. HERHANGİ bir dilde veya ortamda bulunabilecek en zengin maaşları olan bölgeler. ”

Belki bir başkası bu kelimeleri bir meydan okuma olarak alabilir ve Crockford'un liderliğini takip edebilir ve Node.js ve ekosistemi için “iyi kısımları” ve / veya “daha ​​iyi kısımlarını” yazabilir. Bir kopyasını alırım!

Ve tüm projelerde coşku derecesi ve katıksız çalışma saatleri göz önüne alındığında, bu yazı sırasında yapılan olgunlaşmamış bir ekosistem hakkında herhangi bir sözün keskin bir şekilde temperlenmesi bir veya iki yıl veya üç yıl içinde garanti edilebilir. Beş yıl içinde, “2015 Node.js ekosisteminin çeşitli mayın tarlaları vardı. 2020 Node.js ekosisteminin birden fazla cenneti var. ”


9

Uygulamanız çoğunlukla web apislerini veya diğer io kanallarını bağlarsa, bir kullanıcı arayüzü verir veya alırsa, özellikle en çok ölçeklendirilebilirliği veya yaşamdaki ana dilinizi sıkmak istiyorsanız, node.js sizin için adil bir seçim olabilir. javascripttir (veya bir çeşit javascript transpilerleridir). Mikro hizmetler oluşturursanız, node.js de uygundur. Node.js ayrıca küçük veya basit olan her proje için de uygundur.

Ana satış noktası, ön uçların tipik uçurumdan ziyade arka uç şeyler için sorumluluk almasına izin vermesidir. Bir diğer haklı satış noktası ise iş gücünüzün javascript ile başlayıp başlamadığıdır.

Bununla birlikte, belirli bir noktanın ötesinde, modülerliği, okunabilirliği ve akış kontrolünü zorlamak için korkunç bir kesmek olmadan kodunuzu ölçeklendiremezsiniz. Yine de bazı insanlar bu olayları sever, özellikle olaya dayalı bir javascript geçmişinden geliyorlar, tanıdık veya affedilebilir görünüyorlar.

Özellikle, uygulamanızın eşzamanlı akış gerçekleştirmesi gerektiğinde, geliştirme süreciniz açısından sizi önemli ölçüde yavaşlatan yarı pişmiş çözümlerden kanamaya başlarsınız. Uygulamanızda hesaplama yoğun parçalarınız varsa, dikkatli toplama (yalnızca) node.js ile devam edin. Belki http://koajs.com/ veya diğer yenilikler, orijinal olarak dikenli yönleri hafifletir, node.js'yi ilk kullandığım veya yazdığım zamana kıyasla.


3
Node.js uygulamalarını ölçeklendirmek için mevcut birçok yaklaşım vardır ve "yarı pişmiş çözümler", "korkunç hackler" ve "korkunç API" iddialarıyla ilgili herhangi bir referans sunmuyorsunuz. Bunları genişletmek ister misiniz?
Sven Slootweg

Okuyucuya bir egzersiz olarak bırakıyorum, ancak akış kontrolü için sözde çözümlere bakmak yeterli.
Matanster

2
Bu gerçekten bir cevap değil. Mevcut çözümlerin "korkunç hackler" olduğunu iddia edersiniz, ancak bunlardan herhangi birini işaret edemezsiniz. Node.js uygulamalarını ölçeklendirmek için doğru yöntemleri anlayamayacağınızı veya farkında olamayacağınızı düşündünüz mü?
Sven Slootweg

Cevabımı biraz güncelledim. Belki hala şikayetleriniz var, ancak bunun yanlış olduğunu düşünüyorsanız, cevapta eksikliklere dikkat etmek yerine ayrıntılarla yorum yapmalısınız. Bu topluluk imo için daha verimli olurdu.
15'te matanster

-2

Düğüm js nerede ve neden kullanılır birkaç puan paylaşabilirim.

  1. Sohbet, işbirlikçi düzenleme gibi gerçek zamanlı uygulamalar için, sunucudan istemcilere yangın olayı ve verilerin olduğu olay tabanı olduğu için nodejs ile daha iyi gideriz.
  2. Basit ve anlaşılması kolay olduğu için çoğu insanın fikir sahibi olduğu javascript tabanıdır.
  3. Mevcut web uygulamalarının çoğu açısal js ve omurgaya doğru gidiyor, düğüm ile her ikisi de json verilerini kullanacağı için istemci tarafı koduyla etkileşim kurmak kolaydır.
  4. Birçok eklenti mevcut.

Dezavantajları: -

  1. Düğüm, veritabanlarının çoğunu destekleyecektir, ancak en iyisi, karmaşık birleştirmeleri ve diğerlerini desteklemeyen mongodb'dur.
  2. Derleme Hataları ... geliştirici, herhangi bir hata anlaşması uygulaması çalışmayı durduracaksa, her bir istisnayı akıllıca ele almalıdır.

Sonuç: - Nodejs basit ve gerçek zamanlı uygulamalar için kullanmak için en iyisidir .. Eğer çok büyük iş mantığınız ve karmaşık işlevsellik daha iyiyse nodejs kullanmamalıdır. Eğer sohbet ve herhangi bir işbirlikçi işlevsellik ile birlikte bir uygulama oluşturmak istiyorsanız .. düğüm belirli bölümlerde kullanılabilir ve rahatlık teknolojisi ile devam etmelidir.


-3
  1. Düğüm hızlı prototipler için harikadır, ancak bir daha asla karmaşık bir şey için kullanmam. Bir derleyici ile ilişki geliştirmek için 20 yıl geçirdim ve kesinlikle özledim.

  2. Düğüm, bir süredir ziyaret etmediğiniz kodu korumak için özellikle acı vericidir. Tip bilgisi ve derleme zamanı hata tespiti İYİ ŞEYLER. Neden hepsini dışarı atıyorsun? Ne için? Ve dang, bir şey güneye gittiğinde yığın oldukça sık işe yaramaz.


2
Derleme zamanı denetimi almazken, JSDoc istediğiniz tür bilgilerini eklemenize izin verir, böylece geri döndüğünüzde işler daha anlamlı olur. Düzgün bir şekilde ayrışmış (küçük) fonksiyonlar, iyi tanımlanmış ortamları (kapanması) nedeniyle genellikle grok yapmak da oldukça kolaydır. Hatalı yığın izleri, mantığınızı arada bir zaman uyumsuz geri aramayla bölmediğinizden emin olmak için bazı yeniden faktoring işlemleriyle çözülebilir. Zaman uyumsuz geri aramalarınızı aynı kapatma içinde tutmak akıl yürütmeyi ve sürdürmeyi kolaylaştırır.
Rich Remer

2
Derlenmiş dillerle 30 yıl geçirdim, ancak sadece bir yıl kullandıktan sonra JavaScript artık benim tercih ettiğim dil. Sadece çok üretken - Java C # C ++ veya C'den çok daha az kodla daha fazlasını yapabilirim. Ama farklı bir zihniyet. Tiplenmemiş değişken aslında birçok durumda bir avantajdır. JSLINT önemlidir. İşleri eşzamanlı olarak yapmanız gerektiğinde eşzamansız geri aramalar, iş parçacıklarını kullanmanız gereken herhangi bir dilden çok daha güvenli, daha kolay ve sonuçta daha üretken olur. Ve zaten JavaScript bilmek zorunda çünkü tarayıcının dili.
James

Ortaya çıkan endişelere sempati duyuyorum ve kesinlikle evrensel olarak uygulanmasalar da, bunlara yönelik bazı çabaların gösterildiğine dikkat çekiyorum. Javascript kodu ve kütüphanelerinin statik analizinden tür türevi sağlayabilen Tern adında inanılmaz bir proje var . Çeşitli editörler için eklentileri vardır. Ayrıca Typcript, JSDoc ve BetterJS var . Bir de Javascript derleme dilinden biri olan Go var !
joeytwiddle
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.