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
   

   View Slide

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
   

   View Slide

3. Ce talk est une analyse de mes expériences :
   c’est mon opinion !
   Disclaimer
   3
   

   View Slide

4. Client riche = logique métier côté client
   Introduction
   4
   

   View Slide

5. En Web
   React, Vue, Angular, …
   Dialogue via HTTP avec une API
   Introduction
   5
   

   View Slide

6. 2. Mais au fait, pourquoi on développe des
   clients riches ?
   6
   

   View Slide

7. Les utilisateurs ont développé
   de nouvelles attentes
   7
   

   View Slide

8. - Chargement rapide
   8
   

   View Slide

9. - Chargement rapide
   - Interfaces qui les aide et les accompagne
   9
   

   View Slide

10. - Chargement rapide
    - Interfaces qui les aide et les accompagne
    - Formulaires efficaces et facile d’utilisation
    10
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

14. Les clients riches sont utiles pour
    améliorer l’expérience utilisateur
    14
    

    View Slide

15. Si développer un client riche n’améliore pas
    l’expérience utilisateur,
    cela n'apporte que des inconvénients
    15
    

    View Slide

16. 3. Quand les clients riches tournent mal
    16
    

    View Slide

17. Les requêtes HTTP sont très peu fiables
    17
    

    View Slide

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
    

    View Slide

19. Un SLA de 99.999%
    =
    1 erreur sur 100 000 requêtes
    19
    

    View Slide

20. Risques d’erreurs plus élevé
    => nécessité de mieux gérer les erreurs
    => complexité additionnelle
    20
    

    View Slide

21. Le navigateur fait beaucoup de travail pour vous
    21
    

    View Slide

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
    

    View Slide

23. Se baser sur les navigateurs pour gérer
    l’historique, la session ou les cookies
    simplifie énormément votre code
    23
    

    View Slide

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
    

    View Slide

25. Le front-end est un autre métier
    25
    

    View Slide

26. Combien de développeurs(ses) dans votre
    équipe maîtrisent parfaitement à la fois
    React et Symfony ?
    Tous ?
    La moitié ?
    Seulement quelque uns ?
    26
    

    View Slide

27. Une application interactive implique une façon
    de développer différente
    => il faut des compétences spécifiques
    => complexité humaine additionnelle
    27
    

    View Slide

28. Comment lutter contre ces
    nouvelles sources de complexité ?
    28
    

    View Slide

29. Ne pas utiliser de client riche si cela n’améliore
    pas de manière significative l’expérience
    utilisateur
    29
    

    View Slide

30. Savoir faire une balance entre
    expérience utilisateur
    et
    dette technique additionnelle
    30
    

    View Slide

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
    

    View Slide

32. 4. Un client riche dans Symfony 4
    32
    

    View Slide

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
    

    View Slide

34. Webpack Encore
    est absolument génial
    34
    

    View Slide

35. 35
    {% block stylesheets %}
    {{ encore_entry_link_tags('user-registration') }}
    {% endblock %}
    {% block javascripts %}
    {{ encore_entry_script_tags('user-registration') }}
    {% endblock %}
    Twig + Vanilla JS
    

    View Slide

36. 36
    
    Hello world
    
    // user-registration.js
    render(Overriden!, document.getElementById('react'));
    Twig + React
    React écrase le HTML original :
    progressive enhancement
    

    View Slide

37. 37
    <br/>{{ twig_data|json_encode }}<br/>
    Twig + React
    Pas nécessairement besoin d’API
    

    View Slide

38. 38
    Single Page App
    API-platform + create-react-app : deux possibilités
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

41. 41
    Deux dossiers distincts
    ├── api
    │ ├── bin
    │ ├── config
    │ ├── public
    │ ├── src
    │ ├── var
    │ └── vendor
    └── client
    ├── node_modules
    ├── public
    └── src
    

    View Slide

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');
    }
    

    View Slide

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
    

    View Slide

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
    

    View Slide

45. Attention au SEO !
    45
    

    View Slide

46. Attention au SEO !
    Aujourd’hui, la plupart des robots d’indexation
    comprennent bien les applications Javascript
    46
    

    View Slide

47. Pour un site à fort trafic :
    Server-Side Rendering
    Sinon :
    pas forcément nécessaire
    47
    

    View Slide

48. Limenius/ReactBundle
    pour le Server-Side Rendering
    48
    

    View Slide

49. Conclusion
    49
    

    View Slide

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
    

    View Slide

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
    

    View Slide

52. Merci !
    Questions ?
    Titouan GALOPIN
    Product Manager SymfonyInsight
    SfPot Décembre 2018
    Deezer
    52
    

    View Slide