spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »ventrix«

REST und andere API-designs solle man einsetzen, wenn sie auch Sinn machen.
Striktes REST für eine reine Webseite macht meiner Meinung nach nur bedingt Sinn, da sie hier und da dem desgin widersprechen würde (admin-system, user-system, session speichern, template-system..).

Einen modernen Ansatz mit konventionellem Design als wenig Sinnvoll zu entkräften erscheint mir etwas wenig sinnvoll. Genau deswegen ist es ja auch interessant alle diese Designs in die heutige Zeit zu überführen oder über Bord zu werfen. Und danach klang auch für mich die Frage des TE.

Und allein seine Anforderungen die er angibt lassen sogar eine recht gute Schnittstellenbeschreibung zu. Ich möchte aber auch anmerken, dass ich mit modern nicht unbedingt meine, dass dies jetzt auch besser, schneller, einfacher oder was auch immer positives bedeutet. Sondern nur wie sich die jüngeren Entwicklungen so abspielen. Doch oft führt ja das eine zum anderen da dies ja meist die treibenden Bedürfnisse sind.

Hier wird oft enterprise als Begriff im Raum verwendet. Mich wundert , das der Begriff modern und enterprise nicht zu einer Materie/Antimaterie Reaktion führt. Nach meinem Empfinden müsste es das eigentlich.

Zitat von »H5::«

Um mal deinen Titel auf zu greifen: "Moderne Web Entwicklung"

In dem Zusammenhang beißt sich etwas der spezifische Gedanke ob nun nodejs, go, php oder was auch immer als “Backend” zu benutzen.

Dein CMS sollte meine Meinung nach simpel von einem x beliebigen Server transportiert werden können. Sprich aus html/js/css bestehen.

Die Kommunikation findet dann per ReST/Websocket oder was auch immer, sehr definiert statt. Hier kannst du dann ja z.B eine Referenz-Implementation deines Application Servers anbieten (der teilweise heut zu Tage erschreckend einfach aufgebaut ist, da das Meiste in der Application im Browser abläuft).

So bleibst und bietest du viel mehr Flexibilität. Und kannst zwei getrennte Seiten anbieten, die jeder bei Bedarf leicht ersetzen kann.

Zumindest wäre dies in meinen Augen ein modernerer Ansatz. Sprich Web Application Entwicklung statt der Klassischen.

Ich finde den Ansatz interessant. Gerade, wenn es um die Lauffähigkeit auf verschiedenen Webserverumgebungen und Laufzeitumgebungen geht bietet sich hier die Möglichkeit, ein Frontend an verschiedene Serverumgebungen anzubinden - abgesehen davon natürlich, dass es natürlich vom Entwicklungsaufwand her ziemlich viel Arbeit wäre, mehrere Webservices in ASP.NET, PHP, Node.js usw. zu erstellen, nicht zu vergessen, dass das Deployment für unterschiedliche Umgebungen ebenso komplex wäre.
Ich denke aber auch, dass das nicht im Sinne des Threaderstellers wäre, da er ja nach einer Möglichkeit sucht, möglichst komfortabel zu entwickeln und auch eine einfache Möglichkeit sucht, um seine Applikation bereitzustellen bzw. diese einfach zu installieren.

Andernfalls stellt es auch aus meiner Sicht ein ziemliches Risiko dar, die gesamte Verarbeitungslogik der Daten auf den Client in JavaScript auszulagern, da man clientseitiges Javascript auch recht einfach manipulieren könnte.

Interessant wäre vielleicht noch die Nutzung eines MVC Frameworks in Verbindung mit einem ORM Framework, da man sich damit mehr auf die Datenmodellierung und Gestaltung von Templates konzentrieren kann und sich weniger bis gar nicht mit SQL "quälen" muss. Basisaufgaben wie Anlegen, Darstellen, verändern und Löschen von Daten werden von den Frameworks zum großen Teil schon abgedeckt. Das spart extrem viel Zeit und eignet sich gerade zum Erstellen eines solchen kleinen CMS super.

Ich denke du hast mich in ein paar Punkten ein bisschen missverstanden. Um Gottes willen, ich habe nie gesagt, er soll so alle Implementation anbieten. Sondern nur sich eine für ihn handhabbare entscheiden.

Seine Premise war Modern und einfach von Dritten nutzbar. Sprich es ist ein Flexibler Ansatz gewünscht. Monolithisch auf eine Technologie beschränkt ist in meinen Augen nicht Flexibel. Man sieht es auch an den Diskussionen hier, da werden Rocket Science Grenzfälle diskutiert.

Der TE scheint ja auch nur eine einzelne Person zu sein (Physisch gesehen). Da ist es um so wichtiger sich über Handhabbarkeit Gedanken zu machen.

Aber in moderner Web Entwicklung ist das Frontend Webseite nur eines von vielen. Entkoppeln ich Frontend von backend werde ich flexibler und zusätzlich reduziere ich meinen Aufwand. Grenzfälle abtesten überlasse ich denen die sie auch wirklich benötigen.

Hilfreich für die Entkopplung ist eine API und Technologien wie Websockets (es geht ja hier nicht um seinen persönlichen Webauftritt).

So ist es ihm möglich ein sehr einfaches und sauberes Frontend/Backend an zu bieten, kann ein Frontend/Backend seiner Wahl entwickeln und wenn er die Kapazitäten hat es einfach um ein weiteres erweitern oder dies andere erledigen lassen die den Bedarf haben.

Es skaliert alles deutlich sauberer. Derjenige der es braucht kann sich über die Datenbank seiner Wahl Gedanken machen, ob er SQL, Redis, Memcached oder was auch immer noch alles irgendwie zusätzlich benötigt. Aber der TE brach sich erstmal keine Gedanken darüber zu machen.

Einfach etwas Outsourcing betreiben

Edit:

Zitat von »h_dev«

Andernfalls stellt es auch aus meiner Sicht ein ziemliches Risiko dar, die gesamte Verarbeitungslogik der Daten auf den Client in JavaScript auszulagern, da man clientseitiges Javascript auch recht einfach manipulieren könnte.

Bloß nicht! Das Frontend sollte so weit möglich nur Darstellender Natur sein. Die Logik für solche Dinge sollte im Backend stattfinden.