2016-08-07 27 views
3

Die meisten Beispiele, die ich finde, scheinen immer die Daten von URL zu holen.React Redux Data-Abruf: differenzieren Browser/Server-Side-Methode in isomorphe App?

Aber auf der Serverseite, wäre es nicht sinnvoll, Daten direkt aus der Datenbank zu holen?

So im Aktions Schöpfer würde es in etwa so aussehen:

if(typeof document !== 'undefined') 
    fetch("url/posts").then(response => dispatch(receivedPosts(response)) 
else 
    db.select("posts").then(response => dispatch(receivedPosts(response)) 

Was sind die Vor- und Nachteile dieser Methode im Vergleich zu anderen Daten-fetching Methoden?

Antwort

2

Die meisten React/Redux-Anwendungen werden in einer Umgebung erstellt, in der die API-Entwicklung und die UI-Entwicklung voneinander getrennt sind. Die gleichen APIs sind häufig für mobile Apps und andere Desktop-Apps zuständig, sodass eine direkte Datenbankabfrage, wie Sie sie angezeigt haben, für das serverseitige Rendern nicht verfügbar wäre.

In Ihrem Fall scheint es, Ihre Gebäude Full-Stack-App mit einer einzigen Codebasis. Es ist nichts falsch daran, aber es gibt einige Dinge, die Sie wahrscheinlich in Betracht ziehen sollten. Zunächst einmal wird ein wahrscheinlicher Lebenszyklus der Anwendung festgelegt. Es gibt einen großen Unterschied zwischen einem spaßigen kleinen Nebenprojekt, um mehr über einen Stapel zu lernen, einem Startup-Rennen, um MVP auf den Markt zu bringen, und einem großen Unternehmen, das eine Plattform baut, um das Tor zu skalieren. Jedes dieser Szenarien könnte Sie zu unterschiedlichen Überlegungen zum Entwerfen der Ebenen Ihrer App führen. Eine wichtige Frage für Ihre Arbeit ist, ob andere Apps/Plattformen möglicherweise auf dieselben Daten zugreifen müssen und ob verschiedene Teams möglicherweise das Back-End und Front-End verwalten. Mit Node und Mongo ist es sehr einfach, API-Endpunkte zu erstellen, die Ihre React-App anfänglich bereitstellen, aber später von einer nativen IOS-App verwendet werden können. Sie würden auch den Vorteil der Trennung von Bedenken in Wartung und Verbesserung Ihrer App erhalten. Debugging ist oft einfacher, wenn Datenzugriff und UI-Logik vollständig voneinander getrennt sind, da Sie Ihre APIs direkt mit einem Postboten aufrufen können, um festzustellen, ob sie die richtigen Daten bereitstellen.

In Ihrem Fall scheint es, als würde bereits API-Daten von/posts, so dass Sie möglicherweise alle genannten Vorteile erhalten, aber immer noch überspringen ein Netzwerk-Hop durch Umgehen der API, wie Ihr Code-Snippet suggeriert. Dies würde beim Server - Rendering einen Fehlerpunkt weniger bedeuten und wäre ein wenig schneller, aber Sie werden wahrscheinlich nicht viel Geschwindigkeit gewinnen und wenn Sie Netzwerkprobleme mit Ihren APIs haben, werden sie sofort auf der Client - Seite des Servers angezeigt App, damit die Vorteile nicht zu weit gehen.

Ich würde persönlich die Fetch-Aufrufe in der React-App machen und alle meine Datenzugriff/API-Logik in einer Weise trennen, in der das Verschieben von Back-End und Front-End zu zwei separaten Repos nicht zu schmerzhaft wäre in der Zukunft. Dies wird die App an einem guten Ort für ihr zukünftiges Wachstumspotenzial positionieren. Die Vorteile der Trennung von Bedenken aus Gewicht jeder leichten Leistungsschwelle. Wenn Sie mit langsamen Seitenlasten konfrontiert werden, gibt es wahrscheinlich zahlreiche Stellen zum Abstimmen, die oft mit den db-Abfragen selbst beginnen.

+0

Danke. Das macht Sinn. Also, was du sagst ist, dass die meisten React-Apps nicht nur einen, sondern zwei Knoten-Server benötigen, einen für die API und einen für den Render? –

+0

Ja, das ist richtig. Es ist nicht so sehr, dass dies erforderlich ist, sondern oft eine effiziente Trennung von Anliegen/Arbeit. –