Initial Daten
-
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.
-
Das läuft auf der Server Seite.
Du meinst Client? Mir wäre neu, dass Frontend Frameworks am Server laufen? ^^
-
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.
-
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
-
Was ist für denn denn Realtime wenn du Node verwendest?
-
User-Notifications und ein Slack.com-ähnlicher Chat.
-
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...
-
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 ;)!
-
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.
-
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?
-
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.
-
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.
-
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"
-
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