React JS und Backround

[Richard34]

Also, es ist so, dass ich herum experimentiert habe mit React und Datenbankanbindung ect. Da gibt es tools und son zeugs, (express.js wäre eins, auch andere) auch für das Benutzen von Api´s, aber mir kommt immer mehr der Eindruck, dass es vielleicht nicht verkehrt ist Front und Backend zu trennen, gerade wenn man mit React arbeitet. Ich würde mir dann in etwa das so vorstellen, das man z.B Symfony nutzt, dort dann die Datenbankanbindung hat, api´s und sowas alles darüber läuft und React dann quasi nur auf dieses "Backend" zugreift, dem das alles überlässt und sich nur um die Ansicht und Darstellung kümmert, eben das was es ja auch gut kann.

Es ist aber auch so, dass ich mich da schier erschlagen fühle, selbst um React und Symfony miteinander zum laufen zu bringen gibt es schon zig möglichkeiten, wie soll man denn bei all dem wirklich durchblicken und wissen was nun gut ist? Und wie geht ihr vor, versucht ihr Front und Backend immer soweit es geht zu trennen oder macht das jeder dann am ende ein wenig anders?

[JimTheLion]

Moin,

vor 20 Minuten schrieb Richard34:

Und wie geht ihr vor, versucht ihr Front und Backend immer soweit es geht zu trennen

Jep! Je nach Anwendungsfall nutze ich für das Backend dann PHP (erste Wahl ebenfalls Symfony) oder Nodejs.

Nodejs nehme ich, wenn ich mir vorstellen kann, dass ich für das Projekt irgendwann Websockets nutzen möchte, oder wenn die Aufgaben im Backend einfach sehr trivial sind. 

[pr0gg3r]

Also die grobe Architektur, Frontend und Backend zu trennen und per API zu verbinden, ist der richtige Schritt. Der nächste Schritt is zu erkennen, dass dem Frontend (in dem Fall deiner React-Anwendung) es komplett egal ist, wie das Backend entwickelt wurde. Wichtig ist erst mal nur, wie du auf die Daten zugreifen kannst. Hier wäre zum Beispiel die Stichworte SOAP, REST oder GraphQL angebracht. Nehmen wir mal an, du entscheidest dich für REST (was so der erste logische Schritt wäre): eine Rest-API kannst du in allen möglichen Sprachen und Frameworks entwickeln. Da du selber von Symfony gesprochen hast: einfach mal nach "Symfony REST API" suchen. Du kannst aber auch JavaScript verwenden (Stichwort NodeJS und Express). Du kannst aber auch Python (die Alternative zu Express wäre hier Flask) verwenden. Oder NestJS (das eher wie Angular aufgebaut ist). Oder wenn du auf Java stehst, kannst du dir mal Spring Boot anschauen...

vor 4 Stunden schrieb Richard34:

wissen was nun gut ist?

Wirklich "schlecht" ist wohl keine Möglichkeit. Es gibt halt Unterschiede. Wenn du zum Beispiel nur Express verwendest, kümmerst du dich erst mal um alles selber. Nimmst du Symfony, kannst du sicher aus deinen Modellen bestimmt irgenwie deine REST-Endpunkte definieren... Es gibt es auch kein "richtig" oder "falsch"...

[Richard34]

Hm okay.

Also im Prinzp könnte ich es so machen. Nehem wir an ne Anwendung mit Datenbank zugriff und dann soll die noch auf andere externe Dienste wie z.B Wetterdienste, Verkehrdienste e.c.t. zugreifen können, (egal was, haubtsache dafür gibts passende api's). Dann ist das alles, Datenbank, die Api's mit dem Backend verbunden, da geht alles über Symfoni, was mir im Prinzip dann gebündelt die rohen, nakten Daten bereit stellt, daran schleise ich dann irgend ein Frontend an mit z.B dieser Rest Api.

Sollte ich dann z.B ne App haben wollen oder ne Destop-Anwendung, kann ich die einfach nur an dieses Backend "Anschliesen" und muss da nicht erst alles neu einbinden sondern muss nur eine Schnittstelle dafür verwalten, so jetzt meine Grundidee, liege ich da dann in etwa so richtig mit meiner Denkweise?

[Whiz-zarD]

Ja, du liegst da richtig.

Im Idealfall ist die UI komplett entkoppelt und stellt nur ein Detail in deinem System dar. Dann ist es egal, ob die UI eine Web-, Desktop- oder sogar nur eine Konsolenapplikation ist. 

Ich kenne dein Wissensstand nicht aber es kursiert schon länger der Begriff "Onion Architecture" bzw. "Clean Architecture" rum. Diese Softwarearchitekturen stellen die Businesslogik (auch genannt "use cases") in den Mittelpunkt. Also das, womit man auch eigentlich sein Geld verdient. Dort befinden sich dann auch Schnittstellen für externe Dienste, die sie dann implementieren müssen und so ein Dienst kann z.B. deine UI oder auch die Datenbank sein. Dies hat den Vorteil, dass die Businesslogik komplett entkoppelt ist und keine Abhängigkeiten besitzt. Somit lässt sich dann die UI oder auch die Datenbank austauschen und da die Businesslogik überhaupt keine Abhängigkeit zur Datenbank besitzt, lässt sie sich dann auch noch leichter testen. Somit ist es dann auch egal, ob du eine Web-, Desktop- oder nur eine Konsolenapplikation schreibst.

[pr0gg3r]

vor 10 Stunden schrieb Richard34:

Sollte ich dann z.B ne App haben wollen oder ne Destop-Anwendung, kann ich die einfach nur an dieses Backend "Anschliesen" und muss da nicht erst alles neu einbinden sondern muss nur eine Schnittstelle dafür verwalten, so jetzt meine Grundidee, liege ich da dann in etwa so richtig mit meiner Denkweise?

Die API ist die Schnittstelle --> "Application Programming Interface" (to interface = verbinden, interface = Verbindung, Schnittstelle). Du hast vollkommen recht: von wem die Schnittstelle verwendet wird, ist erst einmal egal. Das kann eine Desktop-Anwendung, eine Browser-App, eine Smartphone-App, eine Server-Application, dein Smart-TV oder von mir aus auch ein intelligenter Lichtschalter oder eine Zahnbürste sein. Das ist ja auch der Zweck dahinter. Du machst nicht für jeden Zugriffs-Client eine eigene Zugriffsmöglichkeit, sondern alle nutzen dieselbe API. Und deshalb willst du ja auch davon weg, Webseiten serverseitig zu rendern (zB mit Symfony) hin zu APIs bereitstellen (die auch wiederum mit Symfony gemacht werden könnten) + einzelnen Clients. Deine React-Single-Page-Application hierbei ist auch nur ein Client.

vor 10 Stunden schrieb Richard34:

Dann ist das alles, Datenbank, die Api's mit dem Backend verbunden, da geht alles über Symfoni, was mir im Prinzip dann gebündelt die rohen, nakten Daten bereit stellt, daran schleise ich dann irgend ein Frontend an mit z.B dieser Rest Api.

Dein Symfony rendert dann keine HTML-Seiten mehr, sondern gibt die Daten in einem maschinen-lesbaren Format wie zum Beispiel JSON (JavaScript Object Notation) aus. Warum JSON? Einfach weil das am einfachsten in JavaScript zu verwenden ist (React ist ja auch JS).