Réagir Récupération de données Redux: différencier la méthode navigateur/côté serveur dans une application isomorphe?

Question

La plupart des exemples que je rencontre semblent toujours chercher les données de l'URL.

Mais sur le côté serveur, cela n'aurait-il pas de sens d'extraire des données directement de la base de données?

Ainsi, dans le créateur d'action, il ressemblerait à quelque chose comme:

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

Quels sont les avantages et les inconvénients de cette méthode par rapport à d'autres méthodes de récupération des données?

Answer 1

La plupart des applications React/Redux sont construites dans un environnement où il existe une séparation entre le développement de l'API et le développement de l'interface utilisateur. Souvent, ces mêmes API alimentent les applications mobiles ainsi que d'autres applications de bureau, ainsi une requête db directe comme celle que vous avez montrée ne serait pas disponible pour le rendu côté serveur.

Dans votre cas, il semble que votre application de construction de pile complète avec une base de code unique. Il n'y a rien de mal à cela nécessairement mais il y a des choses que vous devriez probablement considérer. Tout d'abord établit un cycle de vie probable de l'application. Il y a une grande différence entre un petit projet amusant réalisé pour en apprendre davantage sur une pile, une course de démarrage pour obtenir et MVP sur le marché, et une grande entreprise qui construit une plate-forme qui devra élargir la porte. Chacun de ces scénarios peut vous mener à différentes considérations sur la conception des niveaux de votre application. Une question importante spécifique à votre travail est de savoir si d'autres applications/plates-formes peuvent avoir besoin d'accéder à ces mêmes données, et si différentes équipes peuvent éventuellement gérer le back-end et le front-end. Avec node et mongo, il est très facile de créer des points de terminaison d'API qui servent initialement votre application React, mais qui pourraient être utilisés, disons, par une application IOS native plus tard. Vous obtiendrez également l'avantage de la séparation des préoccupations dans la maintenance et l'amélioration de votre application. Le débogage est souvent plus facile lorsque vous avez un accès aux données et que la logique de l'interface utilisateur est complètement séparée, car vous pouvez appeler directement vos API avec quelque chose comme postier pour identifier si elles fournissent les données correctes. Dans votre cas, il semble que vous puissiez déjà diffuser des données API à partir de/posts, vous pouvez donc obtenir tous les avantages mentionnés, mais également ignorer un saut réseau en ignorant l'API comme le suggère votre extrait de code. Cela fournirait un point d'échec de moins dans le rendu du serveur et serait un peu plus rapide, mais vous ne gagnerez probablement pas beaucoup de vitesse et si vous avez des problèmes de réseau avec vos API, ils apparaîtront tout de suite du côté client du serveur. application, de sorte que les avantages ne vont pas loin. Je voudrais personnellement faire les appels de récupération dans l'application React et séparer tous mes accès aux données/logique API de manière à déplacer le back-end et front-end à deux repos distincts ne serait pas trop douloureux A l'avenir. Cela mettra l'application dans une bonne place pour son potentiel de croissance à l'avenir. Les avantages de la séparation des préoccupations sur le poids de toute légère bosse de performance. Si le chargement des pages est lent, il existe probablement de nombreux endroits à régler, en commençant souvent par les requêtes db elles-mêmes.