Différence entre la WebApp qui se connecte à l'API et le rendu dorsal

Question

Parfois, lorsque je crée des outils Web de base, je vais commencer par un backend nodeJS, en créant généralement un serveur API avec ExpressJS. Lorsque certaines routes sont atteintes, le serveur répond en rendant le code HTML d'EJS en utilisant l'état en direct de la connexion, puis l'envoie au navigateur. Cette application affichera généralement un répertoire pour les ressources statiques publiques et les desservira également. J'imagine que cela crée beaucoup de frais généraux pour cette forme d'application web, mais je ne suis pas sûr.

---

D'autres fois, je vais commencer par une API (qui pourrait être la même structure de NodeJS exacte, sans rendu HTML, juste la gestion de l'état et l'exposition API) et je vais construire une page Web Angular2 ou autre HTML qui sera se connecter à l'API, charger des informations sur le chargement et remplir les données de la page.

Ces pages ont tendance à compter sur un grand nombre d'appels AJAX et de jQuery afin de rafraîchir les composants angulaires après le déclenchement d'un certain nombre de rappels asynchrones. Dans cette structure, je vais utiliser un serveur web comme Apache pour servir tous les fichiers et définir les routes, et le JS dans les pages web fera le reste.

---

Quelles sont les forces et les faiblesses des deux? Et pourquoi devrais-je utiliser une stratégie par rapport à l'autre? Sont-ils à la fois viables et dépendants de l'échelle et de l'utilisation? J'imagine que la mise à l'échelle horizontale avec des équilibreurs de charge pourrait fonctionner dans les deux situations.

Answer 1

Il n'y a pas de bonne ou mauvaise approche que vous pourriez choisir. Chacune des approches que vous avez décrites ci-dessus présente des avantages et vous devez choisir celle qui convient le mieux à votre projet.

Certains points que vous pourriez envisager:

traitement côté serveur

• sécurité - Vous ne devez pas exposer des informations sensibles (jetons API, connexions, etc.).

• Plus de contrôle - Vous aurez plus de contrôle sur ce que vous faites avec vos ressources

• « Better » soutien à la clientèle - Certains clients (IE) ne prennent pas en charge mêmes choses que les autres. Rendu HTML sur le serveur plutôt que de le manipuler sur le client vous donnera plus de soutien pour les clients.

• Il peut être plus simple de pré-afficher vos ressources sur le serveur plutôt que de traiter une approche asynchrone sur le client. SEO, partage social etc. - Comment votre serveur envoie des ressources, c'est comment les bots les voient. Si vous pré-rendez tout sur le serveur, vous pourrez gratter votre site, le marquer, etc. Si vous le faites sur le client, il ne verra que la page non-traitée. Cela étant dit, il existe des moyens de contourner cela.

traitement côté client

• Les temps d'attente. Faire des choses côté client améliorera vos temps de chargement.Mais attention à ne pas faire trop de choses car JS est mono-thread et des trucs lourds vont bloquer votre interface utilisateur.

• CDN - vous pouvez servir des ressources statiques (HTML, CSS, JS, etc) de CDN qui sera beaucoup plus rapide que de les servir de votre application serveur directement

• Test - Il est facile de serveur principal moquerai quand tester votre interface utilisateur. Le client est un frontal pour une application/un périphérique particulier, etc. Plus vous mettez de logique dans le client, plus vous devrez répliquer le code entre différents clients. Par conséquent, si vous envisagez d'avoir une application mobile, il sera préférable d'avoir une collection d'API à appeler plutôt que d'inclure votre logique dans le client.

• Sécurité - Tout ce qui s'exécute sur le client peut être entièrement lu par le client. Peu importe combien vous rapetisser, compresser, crypter tout une personne ressource sera toujours en mesure de faire ce qu'il veut avec votre code

Je ne marque pas pro/con sur chaque point de vue, car il est à vous de décider ce que c'est.

Cette liste pourrait continuer encore et encore, je ne voulais pas penser à plus de points parce que c'est très subjectif, et à la fin cela dépend du développeur et de l'application. Personnellement, j'ai tendance à choisir l'approche "client faisant des requêtes ajax" ou un mélange des deux - pré-rendre quelque chose sur le serveur et le client prend soin de repos. Soyez prudent avec ce dernier, car il va briser vos tests automatisés, l'intégration IDE, etc. s'il n'est pas mis en œuvre correctement.

Dernière remarque - Vous devriez toujours faire des validations cruciales sur le serveur. Ne comptez jamais sur les données du client.