Design & Développement web - Le topic des canards qui mangent des cookies

[Orhin]

Sur la précédente ESR je veux bien, mais normalement sur du Firefox 52 ça devrait pas poser de problèmes.

[Fastela]

Est-ce qu'il y a des canards qui ont une expérience avec Voyager pour Laravel? Je cherche un moyen de me faire un CMS / Admin avec Laravel pour mes futurs projets (et virer cette merde de Wordpress) et pour l'instant je suis très agréablement surpris par cette solution.

Est-ce qu'il y a mieux ou c'est le bon choix ?

[Getz]

Est-ce que du monde a déjà utilisé NGRX ou NGXS pour utiliser Redux sur une appli angular? On va migrer depuis AngularJS 1.x, et plutôt qu'essayer de migrer, on va faire une réécriture complète de l'application.

Le concept de Redux semple intéressant, et NGRX a l'air d'être le plus utilisé aujourd'hui. Mais je vois que NGXS a pris énormément d'ampleur en très peu de temps, du fait de sa simplicité et d'une meilleure intégration des concepts d'Angular.

N'ayant encore jamais fait ni d'Angular 2+ (seulement une formation), ni de Redux, vous conseillerez quoi? NGRX? NGXS? ng-Redux? Pas de Redux?

(Et on a pas le choix du framework, sinon je pense qu'on serait partie sur du Vue ou du React...)

[Thomasorus]

Pour angular en tout cas, partez sur la dernière LTS et pas sur la deux. Tout ce que je peux te dire pour Redux c'est ce que j'en ai entendu ici et là et vu dans ma boite (on utilise react) : c'est bien pour les grosses apps quand tu as besoin de partager des infos, mais c'est quand même sacrément complexe au début et vous allez vous gratter la tête pendant un moment si vous avez pas l'habitude. Il faut en plus faire les choses d'une certaine manière avec Redux.

[Dross]

Je me suis intéressé à NGRX après un peu moins de deux ans passé avec Angular2-5, alors qu'on avait déjà une app bien complexe, et je l'ai implanté pour gérer un petit sous-ensemble de l'état de l'application (en gros l'interface est modulable, et ne se module pas de la même manière en fonction des sections, j'ai donc fait un test d'intégration avec NGRX en portant seulement ces fonctionnalités), le reste est resté à l'état de services vers des API REST et donnant accès à des streams RxJS.

NGXS était trop jeune à l'époque pour que j'ose l'installer en prod, mais il est sur ma liste des trucs à tester "en vrai".

Au niveau du bilan, même si je suis assez content du sous-ensemble que j'ai porté sous NGRX, ça m'a convaincu de mon intuition que ce n'est pas un silver bullet, et en état je ne porterai jamais tout le state management de notre app sous ce paradigme (peut-être que NGXS changera la donne de ce coté là, mais il est encore trop tôt pour moi pour le dire). Car le paradigme de services injectables avec des streams RxJS est très solide de son coté aussi, surtout qu'on a un contrôle assez fin dessus.

Je serai toi, je ne mettrai pas les pieds dans ces aspects Redux avant de bien comprendre Angular2+, le framework devrai répondre à tout tes besoins "de base", et reste assez structuré pour te permettre (au besoin) une migration vers NGRX/NGXS par la suite (ou sur les points qui te semblerons utiles, par exemple j'avais fini par faire un mini-redux de mon coté dans un de mes services, c'est justement ça que j'ai porté sur NGRX), ça dépends aussi beaucoup de ton app et de tes données évidemment, je pense que certains types de workflows d'applications profiterons plus ou moins dudit truc.

[Getz]

Pour angular en tout cas, partez sur la dernière LTS et pas sur la deux. Tout ce que je peux te dire pour Redux c'est ce que j'en ai entendu ici et là et vu dans ma boite (on utilise react) : c'est bien pour les grosses apps quand tu as besoin de partager des infos, mais c'est quand même sacrément complexe au début et vous allez vous gratter la tête pendant un moment si vous avez pas l'habitude. Il faut en plus faire les choses d'une certaine manière avec Redux.

On part évidemment sur la dernière version

Je me suis intéressé à NGRX après un peu moins de deux ans passé avec Angular2-5, alors qu'on avait déjà une app bien complexe, et je l'ai implanté pour gérer un petit sous-ensemble de l'état de l'application (en gros l'interface est modulable, et ne se module pas de la même manière en fonction des sections, j'ai donc fait un test d'intégration avec NGRX en portant seulement ces fonctionnalités), le reste est resté à l'état de services vers des API REST et donnant accès à des streams RxJS.

NGXS était trop jeune à l'époque pour que j'ose l'installer en prod, mais il est sur ma liste des trucs à tester "en vrai".

Au niveau du bilan, même si je suis assez content du sous-ensemble que j'ai porté sous NGRX, ça m'a convaincu de mon intuition que ce n'est pas un silver bullet, et en état je ne porterai jamais tout le state management de notre app sous ce paradigme (peut-être que NGXS changera la donne de ce coté là, mais il est encore trop tôt pour moi pour le dire). Car le paradigme de services injectables avec des streams RxJS est très solide de son coté aussi, surtout qu'on a un contrôle assez fin dessus.

Je serai toi, je ne mettrai pas les pieds dans ces aspects Redux avant de bien comprendre Angular2+, le framework devrai répondre à tout tes besoins "de base", et reste assez structuré pour te permettre (au besoin) une migration vers NGRX/NGXS par la suite (ou sur les points qui te semblerons utiles, par exemple j'avais fini par faire un mini-redux de mon coté dans un de mes services, c'est justement ça que j'ai porté sur NGRX), ça dépends aussi beaucoup de ton app et de tes données évidemment, je pense que certains types de workflows d'applications profiterons plus ou moins dudit truc.

Merci pour ton retour d'expérience!
Ce n'est pas une mauvaise idée de commencer un squelette d'application de façon standard pour se faire la main, puis d'essayer d'implémenter NGXS par la suite pour voir ce qui fonctionnerait le mieux avec le workflow de l'application! Je vais faire une version "light" de l'application pour m'imprégner de l'architecture Angular déjà.

Merci

[Orhin]

Car le paradigme de services injectables avec des streams RxJS est très solide de son coté aussi, surtout qu'on a un contrôle assez fin dessus.

J'ai commencé à tester NGXS et je peux te dire que c'est plus proche de ce paradigme que NGRX ne l'est.

[Dross]

Ah cool, je pensais faire un side project en Angular cet été, je vais définitivement l'inclure dedans du coup.

[Orhin]

J'ai commencé à l'utiliser sur un projet pro où je suis tout seul et sur lequel y'a de la marge niveau R&D/délais.
Pour l'instant ça se passe très bien.

Si on prend un schéma classique de ce type :

Service <=> Component

Avec :
- un Service par fonctionnalité/type de donnée
- un Component par page (plus tous les autres d'habillage et d'affichage, mais ça ne rentre pas dans la boucle de données)
- des ReplaySubject pour fournir aux Components l'accès aux données des services
- des méthodes exposées par les Services pour modifier les données (et réaliser les effets de bord comme les appels WS et le stockage local) qui envoient la nouvelle version des données obtenues via les ReplaySubject

Alors avec NGXS ça donne :

Service <=> State <=> Component

Avec :
- un State par type de donnée
- un Component par page (plus tous les autres d'habillage et d'affichage, mais ça ne rentre pas dans la boucle de données)
- un Service par fonctionnalité
- des Select (décris dans le State) pour fournir aux Components l'accès aux données des services sous forme d'observable
- des Actions exposées par le State pour modifier les données, qui peuvent utiliser les méthodes exposées par les Services pour réaliser les effets de bords (genre une action "Fetch data" asynchrone qui va utiliser un appel WS du Service) et les traitement de donnée

Au final ça s'intègre très bien dans l'environnement Angular sans quasiment aucune boilerplate.
T'as forcément un peu plus de code à écrire qu'avec la première méthode mais ça permet de bien formaliser les API internes de ton application.

Le seul gros reproche que je ferais c'est le manque de méthode pour faciliter la mise à jour du State (notamment pour les propriétés profondes dans un objet et surtout pour les tableaux).
Mais de ce que j'ai lu les auteurs de la lib vont bosser là dessus.
Et le fait de pouvoir déclarer très facilement des sous-state (ou des stats parallèles non liées) fait qu'on ne rencontre pas trop le soucis.

[Dross]

Merci pour le heads up !

[SeanRon]

http://cssgridgarden.com/#fr

[William Vaurien]

Je suis en train de reprendre une application Java Spring constituée de plusieurs modules et je viens faire appel à votre sagesse légendaire pour ne pas partir dans la mauvaise direction.

L'appli en question est assez classique 'old-school', composée des modules suivant:
- jpa pour la persistence
- service avec le code "métier"
- batch pour faire les gros traitement la nuit (spring-batch)
- web-service pour exposer quelques services en REST
- UI avec un client en Vaadin (single page application mais connecté à une servlet spéciale, pas directement au web-service)

Avec l'architecture courante nous avons pas mal de dépendances directes (les jars sont importés dans le projet):

jpa <--  service  <-- batchs
                  <-- web-service
                  <-- UI

et je rencontre des difficultés à cause de ça: par exemple Spring-batch bloque la monté de version de Spring dans service, car la version actuelle de nos batchs ne fonctionnent plus avec les versions récente de Spring (spring-batch évolue différement de spring, des pans entiers ont disparu comme un client web bien pratique...).
Le client UI lui aussi peut poser des problèmes car il utilise également Spring. En gros faire évoluer un module a des impacts démesurés à l'autre bout de la chaîne et paralyse l'évolution de l'ensemble.
De plus je suis de plus en plus sollicité par des applications tierces qui veulent avoir accès aux services de l'application.

Pour la version future, je me suis dit qu'il serait pas mal de partir sur une version "complètement web-service". Plus aucune dépendances directes, du code moins dégueu (personne ne pourra ajouter un appel à la base dans un bout du client parce que la feature doit être ajouté pour hier), une véritable réflexion sur l'API de nos services. Plus de conflit de version de Spring entre les modules.
Et puis si un jour nous devons passer le client sur une techno différente, genre Angular ou autre, l'appli sera prête.

Par contre je ne vais pas partir sur du micro-service: je voudrais même rendre le tout plus cohérent: jpa+service+webservice deviennent un seul composant.
Batch et UI deviennent des applications clientes autonomes qui remplaceront leurs appels directs dans la même JVM par des appels aux web-services.

J'ai commencé à travailler sur un prototype avec SpringBoot, ce qui change pas mal du vieux Spring3 et ses gros XML.
Mais je n'arrive pas à mesurer complètement les risques liés à une telle architecture.

Si vous avez déjà fait ce genre de transformation, il faut faire gaffe à quoi ?
J'ai par exemple un peu peur des perfs avec le passage en mode indirect, et je me demande également comment gérer les changements impactant l'API (comme l'arrivée d'un paramètre obligatoire dans une méthode exposée).


Merci les canards

[Sariyah]

Après votre conversation, ma question arrive un peu comme un poil pubien dans la soupe mais l'utilisation de Visual Studio Code dans un cadre d'apprentissage du code vous en pensez quoi ?

[Dross]

@William Vaurien

Je ne connais pas les stack Java, mais si tu fait en sorte que tes services sortent des DTO correctement formatés en JSON, tu ne devrai pas avoir de problèmes.
Et si versionné c'est encore mieux évidemment.

@Sariyah

C'est très bien VS Code, la puissance de pas mal d'outils provenant de VS avec une légèreté digne d'un SublimeText.

[Thomasorus]

Vs Code c'est l'éditeur de texte par défaut de tous les devs maintenant. Il reste encore quelques warriors sur sublime et atom mais ils sont rares.

[Sariyah]

Merci je vais passer dessus dans ce cas. La prise en main n'est pas si évidente que ça au début par contre.

[Orhin]

Vs Code c'est l'éditeur de texte par défaut de tous les devs maintenant. Il reste encore quelques warriors sur sublime et atom mais ils sont rares.

Et ceux qui veulent un vrai IDE sont sur un des logiciel JetBrains.

[GrandFather]

Eclipse et VsCode ici. Eclipse pour les projets Symfony bien mastocs, et VsCode pour les projets rigolos à base de Vue.js.

[Awake]

Perso PHPStorm pour Symfony (avec le plugin qui va bien ) et Webstorm pour TypeScript

[Orhin]

Mais tellement.
Eclipse en 2018.

[Nattefrost]

J'ai des collègues sur Eclipse aussi, avec le thème par défaut et le plugin python. J'ai peur chaque fois qu'ils partagent leur écran.
Pourtant je tolère plein de choses(vim, emacs, sublime, atom, vscode, pycharm, spyder...) mais Eclipse pour du python c'est nein.

[Sariyah]

En fait pas le choix l'apprentissage se fera sur VsCode. Je m'étais habitué à Sublim Text du coup je découvre complètement VS.

[William Vaurien]

@William Vaurien
Je ne connais pas les stack Java, mais si tu fait en sorte que tes services sortent des DTO correctement formatés en JSON, tu ne devrai pas avoir de problèmes.
Et si versionné c'est encore mieux évidemment.

L'avantage de Spring c'est qu'il fait tout le boulot de plomberie: il transforme un objet quelconque en XML ou JSON sans aucune config... Reste juste à définir le modèle des données à transporter...

Par contre je voulais éviter de versionner le plus possible: ça à l'air d'être une sacré merde à maintenir. Comme tous les clients sont internes je pensais faire sans, avec le moins possible de changement bloquant dans l'API.

[GrandFather]

J'ai des collègues sur Eclipse aussi, avec le thème par défaut et le plugin python. J'ai peur chaque fois qu'ils partagent leur écran.
Pourtant je tolère plein de choses(vim, emacs, sublime, atom, vscode, pycharm, spyder...) mais Eclipse pour du python c'est nein.

PyDev ? Je l’utilise aussi. Par contre j’ai un thème custom.

Je sais que le fétichisme des développeurs pour leur langage favori s’étend souvent aux outils qu’ils utilisent, personnellement ça me laisse froid. Tant que ça fait le job... J’ai même essayé de coder du Vue avec Eclipse mais là c’était vraiment trop merdique, et VsCode s’est révélé être une bien meilleure option. Par contre je ne me vois pas travailler sur de très gros projets avec.

[tenshu]

Je me demande quand même comment se débrouille Eclipse, j'avais migré sur Netbeans qui était bien mieux loti et maintenant phpstorm qui semble difficile à battre.

[Orhin]

C'est surtout une question d'inertie et de non connaissance des meilleurs outils de la part des utilisateurs.

[tenshu]

Rappel sur le classement des "meilleurs outils"

[GrandFather]

C'est toi l'inertie. Les meilleurs outils, pour quel contexte ? Si tu peux me citer une killer feature absente d'Eclipse, qui va augmenter notre productivité de 200% et faire tomber les filles en pâmoison, je suis prêt à reconsidérer la question. En attendant, je code et je débogue sans entrave.

[Orhin]

Mais justement, ce n'est pas une "killer feature" qui fait la différence entre Eclipse et les IDE Jetbrains (quoique déjà sur le refactoring il y aurait à dire).
C'est plus un ensemble d'avantages ergonomiques (notamment dans la navigation au sein du code) qui, mis bout à bout, rendent les seconds bien plus agréables et pratiques à utiliser.

[Teocali]

@William

En gros, si je comprends bien, Tu vas créer une application Spring boot qui encapsulera ton composant JPA, ton composant service, et ton composant web-service un poil boosté. et ton composant UI et ton composant Batch passeront des appells REST a cette application ?

Tel que je vois, y'a pas vraiment de risque. Juste s'assuré que les changements de l'API sont retrocompatibles, histoire d'éviter de tout casser.
Si à un moment tu dois introduire un gros changement non retrocompatible, tu sors une nouvelle version de l'API, accessible sur un nouvel endpoint (genre api/v1 et api/v2), mais à part ça, je ne vois pas réellement de soucis.
Par contre, un jeu de test REST pour tester cette histoire de retrocompatibilité n'est sans doute pas un luxe.

Idéalement, faut aussi penser a garder tes JSON simple et de taille réduite. Mieux vaut 3 petits appel qui renvoit chacun un petit JSON qu'un seul qui renvoie un énorme. Ou la rigueur, tu inroduits un moyen pour l'appellant de moduler la taille de la réponse, par exemple en lui fournissant un moyen de spécifier les champs qu'il souhaite voir dans la réponse. Si tout tes appels se font sur le même réseau, et que celui-ci est de qualité, le seul risque, en terme de performance, a ce moment viendra de la serialisation/desarialisation des données, mais si tu utilises Spring, devrait pas pas y avoir de soucis.