[DISKUSSION] Node.js [und Techniken, die darauf bauen]

[keksautomat]

Hallo Forum,

vor Kurzem bin ich auf Node.js gestoßen und mich interessiert hier mal eure Meinungen zu Node.js und Konsorten.
Mit Konsorten meine ich Techniken wie "expressjs", die einen Kickstarter für Nodejs Apps spielen und evtl. sogar bissl was an APIs mitbringen, die es noch mehr erleichtert, Apps mit Node.js zu basteln.

Also:

- habt ihr schon Node.js Apps gebastelt, und wenn ja, was?
- habt ihr Tips, die einen Einstieg evtl. noch leichter machen?

Ich habe im Moment vor, eine App zu bauen, die einen Blog ermöglicht.

Was daran besonders ist? Das ganze soll ohne Datenbank funktionieren. Sprich die Blogeinträge werden einfach vom Dateisystem gelesen.
So hätte ich nur i/o als Bottleneck.
Ist zwar nichts dolles, aber für'n Anfang denke ich mal nicht verkehrt. Und man könnte es ja mal gebrauchen irgendwann - vielleicht.

Evtl. könnte man auch eine kleine API ermöglichen die aus einer anderen App irgendetwas bereitstellt.
Habe gehört, dass Memory Caching ganz gut sein soll.
So muss ich mich zumindest nicht mit Varnish und Kollegen rumärgern.

Gruß

 

[CroneKorkN]

Das ganze soll ohne Datenbank funktionieren. Sprich die Blogeinträge werden einfach vom Dateisystem gelesen.
So hätte ich nur i/o als Bottleneck.

Datenbanken machen so tolle Dinge wie Indizes. Schneller als ein vernünftiges ORDBMS wird deine Datei-basierte Storage-Lösunng also nicht arbeiten und mit zunehmender Datenmenge wird die Differenz größer.

Ansonsten ist Node.js halt eine JS-Runtime auf Serverseite. Als Vorteil wird angesehen, dass man sich mit weniger Sprachen herumschlagen muss. Wenn du Javscript schön toll findest, dann bittesehr Express.js hingegen ist ein Web Application Framework. Sowas gibts in den verschiedensten Sprachen.

Gruß

 

[keksautomat]

Mit JS habe ich weniger am Hut. Da und hier mal bisschen was mit jQuery. Das wars dann aber auch schon. Libs benutzen, aber nichts großartiges selbst gebastelt.
Das DBs Sachen indexieren können, und dadurch natürlich perfomanter sind, ist mir eigentlich klar.
Nur geht es im Fall von oben einfach darum "wie könnte sowas aussehen".
Nicht, ob das technisch durchdacht ist.

 

[CroneKorkN]

Mit JS habe ich weniger am Hut.

Das ist aber der einzige Sinn von Node: JS auf Serverseite Da du da aber nicht mit dem DOM arbeitest, ist hier JQuery fehl am Platze.

edit:
Schau dir dochmal Ruby und Ruby on Rails und als Tut Rails for Zombies an.

edit:
Rails Blog in 15 Minuten: http://guides.rubyonrails.org/getting_started.html

 

[epiphora]

habt ihr Tips, die einen Einstieg evtl. noch leichter machen?

Verabschiede Dich von dem, was Du bisher gelernt hast. Javascript eignet sich aufgrund der Event-Orientierung meiner Meinung nach wunderbar, um damit Webanwendungen zu realisieren. Leider widerspricht das oft den Konventionen, die man bisher jahrelang praktiziert hat.

Das ganze soll ohne Datenbank funktionieren. Sprich die Blogeinträge werden einfach vom Dateisystem gelesen.
So hätte ich nur i/o als Bottleneck.

Das wird sicher kein Problem sein, allerdings reizt Du damit die Vorzüge von NodeJS nicht wirklich aus. Das ließe sich genau so gut in einer nahezu beliebigen anderen Programmiersprache entwickeln. Die Inhalte von der Festplatte zu lesen ist ja fast ein bisschen langweilig, wo NodeJS doch gerade mit Datenbanken wie MongoDB so wunderbar harmoniert.

Das Tolle an NodeJS ist meiner Meinung nach einfach, dass der Server komplett im Speicher gehalten wird und nicht alle Module für jeden Seitenaufruf neu geladen werden müssen. Einzelne Teile Deiner Anwendung können auf Aktionen des Users reagieren, ohne dass die Anfrage durch den ganzen Applikationsstapel gereicht werden muss. Für einen Blog wird das kaum relevant sein, aber bei wirklich interaktiven Webanwendungen macht das einen riesigen Unterschied.

 

[virtus]

Der Beitrag ist nicht mehr ganz aktuell, jedoch kann er dir als prinzipielle Orientierung dienen:
Heise 2x Nein, 4x Ja: Szenarien für Node.js
Solle JavaScript nichts für dich sein, dann kannst du Node.js vergessen, denn es ist, am Ende des Tages, nichts anderes als JavaScript und gerade da herrscht ja häufig eine hass-es-oder-lieb-es Mentalität.

Im professionellen Bereich begegnest du Node.js immer häufiger, falls es bei dir hin zur Entwicklung geht, dann ist es nicht verkehrt sich da bereits Kenntnisse anzueignen.

 

[keksautomat]

@CroneKorkN:

Bitte auch das den restlichen Satz hierzu sehen.
Da ich mich eher als Backend-Entwickler sehe, habe ich weniger mit JS zu tun als es mir evtl. lieb ist.
Pures JS graust mir, klar.
Aber mit jQuery kommt man ja recht schnell rein.
Dennoch nichts, was ich bisher häufiger machen durfte - oder sollte.
Das könnte sich mit Node,- wenn auch auf der "falschen Seite" ja ändern.

@epiphora:

Dass Nodejs sehr perfomant ist, weil es eben ein Server ist, der ständig im Speicher liegt, finde ich auch sehr gut.
Wie das bei größeren Apps aussieht und wie man dort sich vor abstürzen schützt, interessiert mich auch.
Habe schon soetwas wie "forever <app.js>" oder "nodemon <app.js>" gesehen - andere Servertools, die ständig den Status der App überwachen.

@virtus:

Danke für den Beitrag.
Oftmals habe ich mich schon drüber aufgeregt, warum "JS" so "beschissen" funktioniert. Das liegt aber mMn dann wohl eher an der mittlerweilen großen Browseranzahl. Libs wie jQuery versuchen das ja in den Griff zu kriegen, obwohl es mMn nicht deren Job sein sollte.
Bevor irgendetwas mit dem User zu tun hat, sollte da noch eine Instanz vorher draufgucken.
Wie bei HTML5: wo alle sich versuchen zumindest am selben Rad zu drehen.
Das hier und da mal eine Selektbox anders aussieht, als bei den Anderen, finde ich da noch in Ordnung.
Aber dass (so habe ich gehört) einige HTML5 Features fehlen und teilw. erst sehr spät hinzugefügt werden, finde ich "scheisse".

Damit muss ich mich aber ja nicht rumärgern,- wenn ich auf dem Server bin.
Klar, muss ich - oder kann ich - den Client auch mit dem Server sprechen lassen, aber hier helfen mir sicherlich wieder einige andere Libs extra für Node im FE.

//
Ich bleibe mal am Ball mit meinem "Blog" Ideen und versuche sie umzusetzen.
Ob mit, oder ohne DB am Ende. Habe da Lust drauf, mir mal was anderes anzusehen, als immer nur PHP.

Gruß

 

[musv]

Ich hab erst vor kurzer Zeit mal angefangen, mich mit Javascript und CSS3 zu beschäftigen. Bis vor 5 Jahren war ich noch fleißiger PHP-Entwickler.

Javascript ist schon irgendwie beschissen, wenn man die Syntax mal so überblickt.

Allerdings muss man dazu sagen, dass Javascript wohl eher mit einer funktionalen Programmiersprache wie Haskell vergleichbar ist. Und genau das ist das interessante daran. Meiner Meinung nach lohnt es sich sehr, seine Javascript-Kenntnisse zu vertiefen. Die Kombination aus Javascript + AngularJS und Node.js (auf Serverseite) dürfte wohl in nächster Zukunft eine Art Standardtechnologie werden.

Der Hype von Ruby on Rails hingegen scheint verflogen zu sein. Das war vor 2-3 Jahren mal aktuell, hat sich aber wohl irgendwie nicht so recht durchgesetzt. Ich empfand es auch als Nachteil von RoR, dass du zwar in der Standardeinstellung schon ein fast fertiges Paket generierst, kleine Änderungen aber ein enormes Wissen und Verständnis der ganzen Framework-Technologie erfordern. Oder anders: Ein Hello-World-Anwendung ist einfach, aber eine bunte Hello-World-Anwendung erfordert dann schon wieder soviel Einarbeitung, dass du das in anderen Programmiersprachen leichter hinbekommen hättest. Btw. das Framework erzeugt dann im Frontend sowieso wieder einen Teil Javascript.

 

[virtus]

@virtus:
Oftmals habe ich mich schon drüber aufgeregt, warum "JS" so "beschissen" funktioniert. Das liegt aber mMn dann wohl eher an der mittlerweilen großen Browseranzahl. Libs wie jQuery versuchen das ja in den Griff zu kriegen, obwohl es mMn nicht deren Job sein sollte.

jQuery oder AngularJS - übrigens ein sehr schönes client-seitiges Framework aus dem Hause Google - verwendest du doch unter anderem gerade als Abstraktionsebene, um nicht ständig auf Eigenarten von Browsern eingehen zu müssen.

Bevor irgendetwas mit dem User zu tun hat, sollte da noch eine Instanz vorher draufgucken.

Vergleiche es doch allgemein mit Computern und deren Software. Je näher du an der Hardware bist, um so mehr musst du dir die Hände schmutzig machen und dich um Eigenarten kümmern, je mehr Abstraktionsebenen zwischen dir und der Hardware liegen, desto einfacher wird es für dich und du brauchst dich um weniger Details zu kümmern.
Auf unterster Ebene musst du wirklich wissen, wie du welche Signale bspw. an den Drucker und die Grafikkarte sendest, bevor deine Software dem Nutzer einen Druckendialog zur Verfügung stellen kann. Zig Abstraktionsebenen darüber von Treiber bis Browser, musst du in JavaScript nur noch .print() aufrufen und die jeweils darunter liegende Schicht kümmert sich um mehr und mehr Details. In so weit ist es doch verständlich, dass ein Framework letztlich auch als Abstraktionsschicht dir wiederum Details abnimmt. Statt dich mit den Eigenarten des Webbrowsers beziehungsweise JavaScript Engine herum zu schlagen, kannst du dich darauf verlassen, dass das Framework diese Arbeit übernimmt und du dich nur noch um dein eigentliches Ziel kümmern musst.
In PHP hast du doch das gleiche Spiel, gerade PHP abstrahiert wunderschön. PHP kümmert sich mit den jeweils darunter liegenden Schichten (Interpreter ..) darum, dass dein Script korrekt ausgeführt wird, ohne dass du dir nähere Gedanken zu Speicherverwaltung oder ähnlichem machen müsstest.

 

[CroneKorkN]

Das könnte sich mit Node,- wenn auch auf der "falschen Seite" ja ändern.

Dass du dich mit jQuery auseinandersetzt? Wie gesagt, jQuery ist eine DOM-Abstraktion, auf dem Server gibts aber kein DOM und damit wäre jQuery auf Node nach meinem Verständnis wie ein U-Boot auf der Autobahn.

@CroneKorkN:Bitte auch das den restlichen Satz hierzu sehen.

Mich beschleicht das Gefühl wir reden aneinander vorbei

 

[keksautomat]

Ja, wir reden aneinander vorbei. Sorry. Aber macht ja nichts.

Gruß

--- [2015-04-30 08:54 CEST] Automatisch zusammengeführter Beitrag ---

Habe mich gestern nochmal ganz kurz in "sails.js" eingelesen und bin die Instruktionen vom "Getting started" durchgegangen.
Dort lässt sich zum Beispiel sehr einfach eine API erstellen, die zum Beispiel "User" Objekte erzeugt und persistet. (Wo, das lässt sich einstellen)

Was ich allerdings nicht verstanden habe ist, dass ich zwar eine Model.js (User.js) bekomme, es dort aber keine Attribute gibt.
Gebe ich dann eins an, wie von der Doku verlangt, so ist es dennoch egal, was ich dann an diese API hinPOSTe.
Ich kann dort ein völlig unbekanntes Feld hinposten und es wird persistet.

Da muss ich nochmal genauer reinschauen..