Méthodes de séparation du front et du back-end avec une pile complète javascript?
Supposons que j'ai un front-end qui est principalement une application d'une seule page écrite en utilisant angular, grunt et bower. Et supposons que j'ai un backend, qui est principalement juste un REST API assis au-dessus d'un ORM, qui stocke/récupère des objets d'une base de données, en utilisant des choses comme grogner, exprimer et séquencer.
L'application angular fait toutes les choses visuelles que l'utilisateur voit, mais il le fait en étant une interface graphique sur les services fournis par le back-end.
Il serait souhaitable de les séparer en deux bases de code différentes, pour permettre le développement indépendant, la gestion des versions, l'intégration continue, le développement Push, etc.
Ma question est, quelles sont les méthodes disponibles pour le faire proprement? Existe-t-il des meilleures pratiques recommandées pour le javascript à pile complète?
L'option n ° 1 semble être un monolithe, c'est-à-dire "ne les séparez pas". L'avantage est que la chaîne de construction est simple et que tout est en un seul endroit - mais il semble y avoir de nombreux inconvénients; plus difficile à gérer indépendamment, un front cassé signifie un dos non déployable, etc.
L'option # 2 semble être un quasi-monolithe, où la chaîne de construction frontale se traduit par l'écriture d'un tas de fichiers dans le back-end. Le répertoire dist sur le front-end ferait référence à un répertoire sur le back-end, donc essentiellement lorsque le front-end réduit, uglifie, etc., il finit par publier sur le back-end, qui exécute tout.
L'option n ° 3 semble totalement séparée: les serveurs frontaux et principaux exécutent chacun leurs propres serveurs sur des ports différents, et ce sont des projets entièrement séparés. L'inconvénient semble qu'ils doivent être configurés pour connaître les ports des autres; le back-end doit autoriser CORS à partir du front-end, et le front-end doit savoir où tous ces points de terminaison sont censés se trouver.
L'option # 4 pourrait être d'utiliser quelque chose comme docker-compose pour tracer le tout ensemble.
Je suis sûr qu'il existe d'autres options. Quelle est la meilleure pratique recommandée?
C'est une application frontale et dorsale, avec une interface REST entre les deux. Vous avez déjà une séparation complète.
Mon vote est pour l'option # 3. Vous semblez inquiet pour la configuration, mais c'est un peu le point. La configuration vous permet d'avoir une séparation complète sans nécessiter de liaisons de code étroitement couplées. Si vous vous inquiétez de CORS, mettez tout sur un seul domaine. Si vous devez avoir CORS, la meilleure façon de gérer cela est une configuration.
Mais il n'y a pas de "meilleure pratique" ici. La meilleure pratique est celle qui répondra le mieux à vos besoins spécifiques.
Oui, vous devez séparer les deux et traiter l'application frontale comme une application tierce - vous pouvez éventuellement ajouter un autre client, une application mobile par exemple, et si le premier client a été construit de cette façon, votre vie sera plus facile.
L'utilisation de conteneurs Docker ou d'un autre système de déploiement concerne principalement le backend, car le frontal de votre application n'est que des actifs statiques qui doivent être résolus. Vous pouvez héberger ces actifs de manière statique sur votre serveur ou ailleurs comme un CDN comme cloudfront.
Éviter les cors vous fera économiser une petite configuration, mais comme la réponse ci-dessus l'a mentionné, c'est en quelque sorte le point. L'utilisation de cors (et d'authentification par jeton) permettra également de mieux préparer votre backend pour d'autres clients.
Edit: en ce qui concerne les meilleures pratiques de la pile complète js - je dirais simplement ceci, soyez cohérent. Si vous utilisez des promesses (et vous devriez), faites-le des deux côtés. Gardez le même style et formatage js, utilisez les mêmes bibliothèques de test (si possible), etc.