Initial Daten
-
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