Initial Daten

[Shade Of Mine]

Es ist oft einfacher die Daten gleich am Server in den passenden DOM zu packen. Da du am Server dann auch gleich gut cachen kannst und mehr sophisticated Tools am Laufen hast.

Ich weiß jetzt nicht wie github es macht aber was genau interessiert dich denn? Bei Performance ist die korrekte Antwort fast immer "cachen".

Geht es dir darum dass der Ajax Request schneller abgearbeitet wird oder dass du kein Nachladen siehst? Kein Nachladen kannst du ja damit "verstecken" dass du einfach die Daten beim initialen Client Request schon mitschickst - am besten gleich als HTML Fragment.

Wo wir wieder einen Vorteil vom "HTML am Server bauen" haben. Du kannst die HTML Fragmente per Ajax nachladen oder eben alles Fragmente am Server schon zusammen bauen.

Aber bevor ich vom 100. ins 1000. gehe - was genau willst du denn erreichen?

[nokk]

Ich hatte mich in den letzten Tagen bissl mit EmberJS und NodeJS beschäftigt - daher die Frage, wie die initialen Daten bei strikter Trennung von Server/Client zum Client kommen, ohne dass der Client irgendwas Laden sieht.

Aber um tatsächlich eine ordentliche Frage bzw. mein Ziel zu formulieren; wie bekomme ich in einer NodeJS-Applikation mit EmberJS Frontend die Daten zum Client, ohne sie über eine API zu holen (eben nur für den initialen Request)?
Ich rufe also localhost:1234 auf wo meine Applikation rennt und mein NodeJS Server liefert mir mein Frontend. Wie aber schicke ich dort direkt die Daten mit (nachdem überhaupt entschieden wurde, ob wir den Login oder die Startseite sehen)? So Sachen wie "wer ist der Benutzer", "Dinge auf der Startseite" (eben wie bei GitHub ein Feed), "vom Admin konfigurierte Sachen" (wie z.B. Applikations-Version, Copyright, etc.) - eben alles was aus einer Datenbank kommt, aber nicht via AJAX nachgeladen werden, sondern direkt geladen soll.

Mir ist bewusst, wie ich mit NodeJS und z.B. express-handlebars Daten an den Client sende;

app.get('/', function(req, res) {
	var data = {
		user: /* ... */,
		feed: /* ... */,
		/* ... */
	};

	res.render('index', data);
});

So wird mein Template direkt vom Server gerendert und die entsprechenden Daten direkt biem Rendern eingefügt. Wie aber habe ich Zugriff auf diese Daten bei einem EmberJS Frontend?

[Shade Of Mine]

Stell dir Endpoints vor, sagen wir mal "userinfo" und "currentfeeds". Diese liefern dir jeweils ein HTML Fragment mit dem jeweiligen Inhalt.
Nun macht der Endpoint "index" dir die HTML Struktur geben und die Ajax Calls initialisieren um "userinfo" und "currentfeeds" zu laden. Aber "index" könnte ja auch einfach das ergebnis von "userinfo" und "currentfeeds" schon am Server ermitteln und direkt als HTML in den response einbetten.

Klar ist es von der Trennung her hübscher wenn du keine doppelte Logik hast - aber manchmal ist Performance eben wichtiger. Und so schlimm ist es auch nicht - du hast ja keinen doppelten Code. Der Controller klebt ja quasi Model und View zusammen. Du kannst also Model und View ja auch in einem anderen Endpoint zusammen kleben.

Ein Endpoint sieht idR ja so aus:
lese Request Daten
hole Daten vom Model
packe Daten in die View
sende die Daten zum Client

Und die mittleren 2 Punkte kannst du in einem anderen Endpoint ja ebenfalls machen

[nokk]

Aber "index" könnte ja auch einfach das ergebnis von "userinfo" und "currentfeeds" schon am Server ermitteln und direkt als HTML in den response einbetten.

Sowas in der Art dachte ich schon; wie aber gesagt, weiß ich eben nicht wie das im expliziten Fall von Node und Ember (oder einem SPA Framework nach Wahl) aussehen soll.

[Shade Of Mine]

nokk schrieb:

Aber "index" könnte ja auch einfach das ergebnis von "userinfo" und "currentfeeds" schon am Server ermitteln und direkt als HTML in den response einbetten.

Sowas in der Art dachte ich schon; wie aber gesagt, weiß ich eben nicht wie das im expliziten Fall von Node und Ember (oder einem SPA Framework nach Wahl) aussehen soll.

Ember hat damit nichts zu tun. Das läuft auf der Server Seite. Dort hast du ja Controller, Models und Views. Und der index Controller erstellt eben eine View die die Daten aus allen passenden Modulen zusammen sucht.

Alternativ kannst du auch in index ja nur den passenden JS Code generieren der eben anstatt einen ajax request zu machen diese Daten schon direkt verarbeitet.

Im Prinzip ist es eben eine Frage was du genau verwendest. NodeJS ist halt nicht wirklich toll für komplexe Sachen.

[nokk]

Das läuft auf der Server Seite.

Du meinst Client? Mir wäre neu, dass Frontend Frameworks am Server laufen? ^^

[Shade Of Mine]

nokk schrieb:

Das läuft auf der Server Seite.

Du meinst Client? Mir wäre neu, dass Frontend Frameworks am Server laufen? ^^

Ich meine Server. Deshalb habe ich ja auch gesagt "Emeber hat damit nichts zu tun".

Der Server muss dir ja irgendwie Daten schicken, oder? Und genau diese geschickten Daten passt du an.

Oder du lässt es einfach sein und lebst mit den langen Wartezeiten. Das ist einfacher.

[nokk]

Ach, dachte der Satz bezieht sich noch auf Ember. Dann isses natürlich verständlich.

Zum Thema "NodeJS ist bei größeren Sachen eher nicht so toll"; keine Ahnung noch, bisher nur kleinere NodeJS Sachen gemacht. Die Entwicklung ist aber relativ einfach und so Sachen wie socket.io passen grad zu dem, was ich mache. Alternativen gäbe es zwar, aber dass meiste davon wäre völliges Neuland für mich; Java mag ich außerhalb der Arbeit nicht sonderlich, PHP ist bei Realtime eher nicht so toll, und Python/Ruby/etc. kann ich einfach zu wenig um a) zu sagen ob sie geeignet wären und b) um damit was passables auf die Beine zu stellen in halbwegs realistischer Zeit

[Shade Of Mine]

Was ist für denn denn Realtime wenn du Node verwendest?

[nokk]

User-Notifications und ein Slack.com-ähnlicher Chat.

[Shade Of Mine]

nokk schrieb:

User-Notifications und ein Slack.com-ähnlicher Chat.

Ich wüsste nicht was daran Realtime sein sollte.

Facebook läuft zB auf PHP. Just sayin...

[noder]

Also ich finde NodeJS echt super! Ich habe schon so einige hoch skalierbare Anwendungen damit entwickelt und bereue es nicht. Meistens sind es eben SOCKET basierte Anwendungen oder RESTful Webservices.

Auch eine normale Homepage oder ein Portal direkt mit NodeJS in Verbindung mit (z.B. dem genannten EmberJS) zu entwickeln ist super.

Es wurden ja schon mögliche Wege aufgezeigt. Asynchrones Laden von Teilelementen etc.

Man muss sich das Gesamtprojekt ansehen und herausfiltern wer, wann, wo und wie mit der Applikation arbeitet. Welche Infos müssen direkt erkennbar sein welche können über ein lazy loading nachgeladen werden etc etc...

Ab und an ist ein Ausflug in das reine Projektmanagement (Anforderungsanalyse) ein guter Anfang ;)!

[PRIEST]

Shade Of Mine schrieb:

Facebook läuft zB auf PHP. Just sayin...

Ja, zumindest das Frontend - allerdings mit/auf HHVM.
Andere Teile sind doch im Backend mit Java und oder D entwickelt.

[nokk]

Shade Of Mine schrieb:

nokk schrieb:

User-Notifications und ein Slack.com-ähnlicher Chat.

Ich wüsste nicht was daran Realtime sein sollte.

Facebook läuft zB auf PHP. Just sayin...

Mir wäre nicht bewusst, wie ich z.B. Notifications ohne Polling in PHP hinbekomme. Der Chat von Facebook ist meines Wissens nach in Erlang geschrieben - auch hier hätte ich in PHP keine Ahnung wie das realisiert werden sollte, sei er noch so rudimentär.

Node ist da etwas einfacher und erlaubt eben solche Dinge relativ einfach hinzukriegen.

Ja, zumindest das Frontend

Wie definiert sich Frontend hier? Meines Erachtens ist Frontend immer das, was der User sieht - und soweit ich weiß, wird PHP vom Server bearbeitet und schickt lediglich antworten, wodurch es eigentlich Backend wäre, oder?

[PRIEST]

nokk schrieb:

Ja, zumindest das Frontend

Wie definiert sich Frontend hier? Meines Erachtens ist Frontend immer das, was der User sieht - und soweit ich weiß, wird PHP vom Server bearbeitet und schickt lediglich antworten, wodurch es eigentlich Backend wäre, oder?

Um das zu Beantworten muss man wissen welche Herangehensweise gewählt wird. Bei einer Client-Server-Architektur ist der Server das Backend und die Anwendung, die beim Client ausgeführt wird das Frontend.

Bei einer Datenbankanwendung (z.B. einer Homepage) wird oftmals schlicht die Datenbank an sich als Backend bezeichnet und die Aufbereitung der Daten um diese dem User übersichtlicher und verständlicher darzustellen als Frontend bezeichnet.

Ein weiteres Beispiel wäre z.B. eine Software die als GUI ein paar Buttons hat und diese Buttons eine .EXE oder ein SHELL-Script ausführen. GUI = Frontend, EXE & Scripts = Backend.

Im Grunde ist deine Aussage korrekt. Frontend == "Was der User sieht".

Bei Facebook ist das nicht anders, die Daten werden aufbereitet und dem User zur schau gestellt. Natürlich wird bei Facebook auch viel mit JavaScript gearbeitet. Aber diese JavaScript wird über die Scripts für das "Frontend" dort platziert wo es benötigt werden.

[Shade Of Mine]

nokk schrieb:

Mir wäre nicht bewusst, wie ich z.B. Notifications ohne Polling in PHP hinbekomme. Der Chat von Facebook ist meines Wissens nach in Erlang geschrieben - auch hier hätte ich in PHP keine Ahnung wie das realisiert werden sollte, sei er noch so rudimentär.

Gehen tut alles. Eine Sprache ist nur ein Tool und wenn du willst kannst du auch PHP zu einer .exe kompilieren. Sinnhaftigkeit ist natürlich ein anderes Thema.

Bei Chats würde ich aber sowieso empfehlen lieber einen IRC Server zu verwenden, das erspart viel unnötige Arbeit.

[nokk]

Bei einer Datenbankanwendung (z.B. einer Homepage) wird oftmals schlicht die Datenbank an sich als Backend bezeichnet und die Aufbereitung der Daten um diese dem User übersichtlicher und verständlicher darzustellen als Frontend bezeichnet.

Naja, auch eine einfache Homepage die Daten aus einer Datenbank holt, braucht eine Schicht zwischen UI und Datenbank, die die Daten aus der DB holt. Folglich würde ich auch bei sowas PHP (oder wie auch immer die Daten aus der Datenbank gezogen werden) immer noch als Backend bezeichnen.

Gehen tut alles. Eine Sprache ist nur ein Tool und wenn du willst kannst du auch PHP zu einer .exe kompilieren. Sinnhaftigkeit ist natürlich ein anderes Thema.

Weswegen wir bei "ich wollts mal mit NodeJS versuchen" sind

Bei Chats würde ich aber sowieso empfehlen lieber einen IRC Server zu verwenden, das erspart viel unnötige Arbeit.

Notifications wäre das gleiche Thema - sozusagen aber nur ein "Einweg-Chat"

[PRIEST]

nokk schrieb:

Naja, auch eine einfache Homepage die Daten aus einer Datenbank holt, braucht eine Schicht zwischen UI und Datenbank, die die Daten aus der DB holt. Folglich würde ich auch bei sowas PHP (oder wie auch immer die Daten aus der Datenbank gezogen werden) immer noch als Backend bezeichnen.

Das kannst du auch gerne so tun, aber da verwirrst du vll viele andere.

Stell dir das mal bildlich vor [FRONTEND] + [BACKEND]. Laut deiner Aussage ist das Frontend einfach da, ohne programmiert zu werden. Denn selbst wenn du mir jetzt sagst das "JavaScript" + HTML bei dir als Frontend eintreten, müssen diese Teile irgendwie Content bezogen angezeigt werden. Wie passiert das denn? (Mit Kopplung an die Datenbank) Genau, über ein "Frontend"-Script zum beispiel mit PHP. Wenn du allerdings alles Abkoppelst und die Daten in ein Konstrukt (z.B. API) packst um die Daten aus der Datenbank zu laden, und du verwendest dieses Konstrukt um im Frontend Bezug zur Datenbank zu nehmen, dann ist das durchaus so richtig. Aber das wäre dann wieder eine andere art von Architekturpattern. (Obwohl das alles so larifari Bezeichnungen sind) mMn...

Es gibt immer mehrere Wege etwas aus zu zeichnen. Andere Bezeichnen ein Backend als "Administartiveoberfläche". Vll denkst du komplizierter als es eigentlich ist.

Grüße