L'intégration de Vue.js dans un framework Backend
Un retour d’expérience
- Adepte du Fomo
- Plusieurs technos testées sur plusieurs langages
- Toutes en production depuis plusieurs mois
- Beaucoup d'échanges avec d'autres développeurs
Rapides rappels historiques
Application monolithique - peu de JS
vs
Microservices - Beaucoup de JS
Rapides rappels historiques
- Intéractions annecdotiques avec jQuery
- Arrivée de Webpack, React, Vue, etc
Framework Front et Back : deux approches différentes
- 1. Vue / React != Rails / Laravel
- 2. Nuxt / Gatsby ~= Rails / Laravel
- 3. Différence de maturité / qualité des écosystèmes
- 4. Fonctionnement côté client vs serveur
- 5. La double peine du JS
Que se passe-t-il après le Getting Started ?
- 📦 Les features out-of-the-box
- 💅 Documentation plus jolie que complète
- 🛠 Tooling et écosystème très jeune
Comment faire cohabiter ces deux approches ensembles ?
Méthode 1 - La progressive
Utilisations de Laravel Mix / Webpacker
Component Vue dans des vues Blade / erb
Products
<%= render @products %>
Méthode 1 - La progressive
Les scoped slots sont vos amis
<%= image_tag("product.jpg", "@click.prevent": "handleClick") %>
Méthode 1 - La progressive
Les props aussi
- Pas besoin d'API
- Un seul endpoint
- Helpers de Rails disponibles
Méthode 1 - La progressive
- Pratique pour des composants "simples"
- Surtout fait pour aider l'UI
- Faire cohabiter des technos différentes ensembles
Méthode 2 - La complète
Découpage complet entre Front et Back
- Deux repos en général
- Application front "autonome"
- Pratique pour les apps multiplateformes
Méthode 2 - La complète
A la mode mais ...
- Deux apps à déployer
- Plus difficile de savoir d'où vient un problème
- Trouver les responsabilités, qui fait quoi ?
Méthode 3 - L'hybride
Fuuuuusion !
Méthode 3 - L'hybride
1 repo pour 2 applications
- Application Vue CLI dans un sous-dossier de Rails
- Même processus de compilation des assets
- Rails comme serveur d'API et de templeting pour une seule page
Méthode 3 - L'hybride
Demo time 🎉
Méthode 3 - L'hybride
Pratique mais...
- Code très (trop ?) séparé - cf: Pluralize
- Overkill dans la plupart des cas ?
- Pratique pour des apps très orientées UI
- Pratique quand une API est obligatoire à côté
Méthode 3 - L'hybride
Pas de solution miracle 😳
Quels sont vos objectifs, pour vous et vos utilisateurs ? 🤔
Le meilleur des deux mondes
Quelles solutions ?
Turbolinks, Rails UJS et Vue ! 🔥
- Simplicité d'une app Rails et plus encore
- Réactivité d'une SPA
- Des perfs côté clients et serveurs
Le meilleur des deux mondes
Quelles autres solutions ?
def render_component(component, props = {})
props = props.map do |key, value|
[key, value.to_json].join('=')
end.join(' ')
render inline: "<#{component} #{props} />", layout: :application
end
class ProductsController < ApplicationController
def index
render_component 'ProductsList', { ':products': Product.all.to_json }
end
end
HDD
Hype-Driven Developement
Quel problème essayez-vous de résoudre ?
Hype-Driven Developement
Beaucoup de problèmes qui n'existaient pas avant
- Ecosystème JS dépendant du client
- Des équipes super spécialisées
- Complexité dans l'architecture / choix de design
- Duplication de code (validations, getters, logique métier)
Hype-Driven Developement
Vous n'êtes pas Facebook.
Conclusion
Quelques liens
