Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Titouan Galopin

December 18, 2018
Tweet

More Decks by Titouan Galopin

Other Decks in Programming

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