Packaging angular2/typescript dans Rails et problématiques SCM en bonus

Bonjour la communauté,

J’arrive du monde java et je m’intéresse depuis peu à Rails et Angular 2. Tant qu’à faire, autant partir sur une techno qui pourrait l’emporter dans le futur :)
La question que j’ai porte sur comment intégrer Rails et Angular 2, comment gérer la «compilation» typescript vers javascript et quoi mettre dans mon gestionnaire de version (disons git).

Ma première idée était de partir sur les mécanismes internes de rails (assets plugin) pour gérer angular2 mais en réfléchissant un peu, ça paraît assez prise de tête. De ma compréhension, le plugin est surtout dédié à la gestion de libs javascript, pas bien plus.
Donc je me dis, autant tout mettre dans public et gérer le cycle de vie avec npm, comme proposé sur le 5 mn tuto angular2. Mais là, je vois plusieurs problèmes :

  1. Le cycle de vie de mon frontend est maintenant décorellé de mon backend
  2. Les fichiers source ts, de build (package.json et co) sont accessibles dans mon appli déployée
  3. Les fichiers javascript résultant des ts (.js et .js.map) sont présents dans ma gestion de version et change à chaque version

La solution idéale que je verrais serait de versionner le source de mon frontend dans un dossier dédié, lancer npm depuis rails (s’il existe un gem pour ça) pour générer le code dans public (voire app/assets mais ça peut être plus tricky). Le hic avec cette solution : faut la bonne version de node/npm d’installée sur la machine de build aux côtés de rails, quid de heroku ?

Donc je me dis que finalement, la solution est peut être de faire deux projets différents, un pour le back, l’autre pour le front, avec leurs propres cycles de vie et déployer sur deux ‘serveurs’ différents puis faire pointer le front vers le back.

Comment faites vous ? Quelle est votre vision de la problématique ? (notez qu’on a le même problème en java mais jme dis que les rubyistes sont peut être plus débrouillards que nous :))

Merci

Personnellement, j’aime bien l’approche ou les deux projets sont découplés. Ça permet de réellement réfléchir à son API, d’éviter qu’elle change en permanence, et de limiter le couplage entre la webapp et l’API.

Au niveau gestion de sources, les fichiers produits par le build ne doivent pas être présents. S’ils le sont, tu risques de tomber sur des conflits à résoudre qui n’ont pas lieu d’être. Pour faire simple, dans un projet typescript, les fichiers *.js et *.js.map doivent être ignorés.

Par contre, je ne connais pas rails donc je peux pas aider beaucoup plus que ça …

Merci pour ta réponse. Ça revient à ce que j’imaginais faire, même si ça sous entend que le back et le front aient des cycles de vie différents.
Dans le cas de heroku par contre ça amène une petite contrainte : j’aurai besoin d’un serveur embarqué pour servir mon application cliente.

En fait la problématique ne serait pas bien différente avec Java.

Premièrement comme indiqué, et comme tu as déjà dû le remarquer avec Java, on ne gère pas en configuration le résultat de transformation (compilation, transpilation, etc.).

Second point, il est grandement recommandé de distinguer le cycle de vie de tes “assets”. Cela te permet non seulement de faire vivre indépendamment le client et le serveur. Mais les assets du client sont aujourd’hui destinés à être servi par des CDN.

Si tu tiens à les garder liés dans un seul dépôt, je te conseille tout de même de les séparer dans deux répertoires. En local, tu peux soit servir directement les .ts (et autres .scss) ou bien leurs résultats. Quoiqu’il en soit tu peux utiliser un Apache/nginx frontal pour héberger les deux “projets” sur le même “domaine”.
Lors de la génération de la livraison, tu génères deux packages qui seront déployés de manière similaire.

Ah, j’avais pas pensé aux CDN, c’est vrai que c’est plus propre. J’étais resté sur l’approche embarquer le front dans le déploiement du back comme au siècle dernier :)

Donc on confirme que les pratiques actuelles s’orientent vers plusieurs livrables différents : un pour la partie back et un livrable par client.

Merci pour vos réponses

Cheers

Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s