Développer un client riche React dans un projet Symfony 4

Transcript

1. Développer un client riche React dans un projet Symfony 4 Titouan GALOPIN Product Manager SymfonyInsight SfPot Décembre 2018 Deezer 1
2. Agenda 1. Introduction 2. Mais au fait, pourquoi on développe des clients riches ? 3. Quand les clients riches tournent mal 4. Un client riche dans Symfony 4 2
3. Ce talk est une analyse de mes expériences : c’est mon opinion ! Disclaimer 3
4. Client riche = logique métier côté client Introduction 4
5. En Web React, Vue, Angular, … Dialogue via HTTP avec une API Introduction 5
6. 2. Mais au fait, pourquoi on développe des clients riches ? 6
7. Les utilisateurs ont développé de nouvelles attentes 7
8. - Chargement rapide 8
9. - Chargement rapide - Interfaces qui les aide et les accompagne 9
10. - Chargement rapide - Interfaces qui les aide et les accompagne - Formulaires efficaces et facile d’utilisation 10
11. - Chargement rapide - Interfaces qui les aide et les accompagne - Formulaires efficaces et facile d’utilisation - Réutilisation de patterns d’UI d’autres sites 11
12. - Chargement rapide - Interfaces qui les aide et les accompagne - Formulaires efficaces et facile d’utilisation - Réutilisation de patterns d’UI d’autres sites - Multiples clients sur différents appareils 12
13. - Chargement rapide - Interfaces qui les aide et les accompagne - Formulaires efficaces et facile d’utilisation - Réutilisation de patterns d’UI d’autres sites - Multiples clients sur différents appareils 13 Expérience utilisateur Presque expérience utilisateur
14. Les clients riches sont utiles pour améliorer l’expérience utilisateur 14
15. Si développer un client riche n’améliore pas l’expérience utilisateur, cela n'apporte que des inconvénients 15
16. 3. Quand les clients riches tournent mal 16
17. Les requêtes HTTP sont très peu fiables 17
18. Combien de fois est-ce qu’un appel de méthode PHP ne fonctionne pas, de manière aléatoire ? 1 fois sur 1 000 000 000 ? 1 fois sur 1 000 000 000 000 000 000 ? En pratique, jamais ? 18
19. Un SLA de 99.999% = 1 erreur sur 100 000 requêtes 19
20. Risques d’erreurs plus élevé => nécessité de mieux gérer les erreurs => complexité additionnelle 20
21. Le navigateur fait beaucoup de travail pour vous 21
22. Quand est la dernière fois que vous avez eu besoin de développer votre propre gestion de session en PHP ? En pratique, jamais ? 22
23. Se baser sur les navigateurs pour gérer l’historique, la session ou les cookies simplifie énormément votre code 23
24. Ne plus se baser sur les comportements natifs des navigateurs (JWT, react-router, ...) => nécessité de beaucoup redéfinir soit même => complexité additionnelle 24
25. Le front-end est un autre métier 25
26. Combien de développeurs(ses) dans votre équipe maîtrisent parfaitement à la fois React et Symfony ? Tous ? La moitié ? Seulement quelque uns ? 26
27. Une application interactive implique une façon de développer différente => il faut des compétences spécifiques => complexité humaine additionnelle 27
28. Comment lutter contre ces nouvelles sources de complexité ? 28
29. Ne pas utiliser de client riche si cela n’améliore pas de manière significative l’expérience utilisateur 29
30. Savoir faire une balance entre expérience utilisateur et dette technique additionnelle 30
31. Utiliser des (petits) clients riches uniquement là où c’est utile (et oui, peut-être que c’est utile pour toute votre application, mais pas forcément) 31
32. 4. Un client riche dans Symfony 4 32
33. A titre personnel, j’utilise généralement 1 de ces 3 niveaux d’intégration selon le projet 33 Pas de Javascript ou VanillaJS React seul sur certains composants spécifiques Single Page App complète React + React-Router + Redux
34. Webpack Encore est absolument génial 34
35. 35 {% block stylesheets %} {{ encore_entry_link_tags('user-registration') }} {% endblock %} {% block javascripts %} {{ encore_entry_script_tags('user-registration') }} {% endblock %} Twig + Vanilla JS
36. 36 <div id="react"> Hello world </div> // user-registration.js render(<div>Overriden!</div>, document.getElementById('react')); Twig + React React écrase le HTML original : progressive enhancement
37. 37 <script type="application/json" type="app-data"> {{ twig_data|json_encode }} </script> Twig + React Pas nécessairement besoin d’API
38. 38 Single Page App API-platform + create-react-app : deux possibilités
39. 39 Single Page App API-platform + create-react-app : deux possibilités Deux dossiers distincts dans le repository Idéal dans le cas de noms de domaine différent
40. 40 Single Page App API-platform + create-react-app : deux possibilités Deux dossiers distincts dans le repository Idéal dans le cas de noms de domaine différent React intégré dans Symfony Utilise Symfony comme proxy (route wildcard vers Twig qui appelle l’app React)
41. 41 Deux dossiers distincts ├── api │ ├── bin │ ├── config │ ├── public │ ├── src │ ├── var │ └── vendor └── client ├── node_modules ├── public └── src
42. 42 React intégré dans Symfony /** * @Route("/app") * @Route("/app/{wildcard}", requirements={"wildcard"=".+"}) */ public function appAction(): Response { return $this->render('react-app-index.html.twig'); }
43. 43 Pas de Javascript ou VanillaJS React seul sur certains composants spécifiques Single Page App complète React + React-Router + Redux Symfony gère l’état et la logique métier Utilisation de JS comme progressive enhancement Client complexe qui gère l’état et la logique métier API-platform, React, React-Router, Redux
44. 44 Pas de Javascript ou VanillaJS React seul sur certains composants spécifiques Single Page App complète React + React-Router + Redux Logique métier : PHP Routing : Symfony Vue : Twig Stockage : Doctrine Logique métier : PHP Routing : Symfony Vue : Twig + React Stockage : Doctrine Logique métier : JS Routing : React-Router Vue : React Stockage : API-platform
45. Attention au SEO ! 45
46. Attention au SEO ! Aujourd’hui, la plupart des robots d’indexation comprennent bien les applications Javascript 46
47. Pour un site à fort trafic : Server-Side Rendering Sinon : pas forcément nécessaire 47
48. Limenius/ReactBundle pour le Server-Side Rendering 48
49. Conclusion 49
50. 50 Pas de Javascript ou VanillaJS React seul sur certains composants spécifiques Un entrypoint JS par page Progressive enhancement via JS/React Très fiable et flexible car basé sur HTTP et le navigateur
51. 51 Pas de Javascript ou VanillaJS React seul sur certains composants spécifiques Single Page App complète React + React-Router + Redux Un entrypoint JS par page Progressive enhancement via JS/React Très fiable et flexible car basé sur HTTP et le navigateur API + client riche Projets séparés Plus complexe car redéfinit des comportements natifs
52. Merci ! Questions ? Titouan GALOPIN Product Manager SymfonyInsight SfPot Décembre 2018 Deezer 52