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

[Awake]

J'ai regardé Mercure c'est vraiment sortir le bazooka pour tuer une mouche, le protocol est tellement simple à la base

[raaaahman]

Y'a des cas d'utilisations où c'est bien plus efficace qu'un mail ou tout autre medium de communication, tant écologiquement que fonctionnellement. Dans mon cas, les notifications servent à alerter en temps réel les utilisateurs d'incidents de production survenus sur les outils métiers qu'ils utilisent.

Okay. Quand ils sont sur leur lieux de travail et connecté à leur intranet du coup? Et j'imagine qu'en cas de déconnexion il y a un reppli vers les mails / SMS.

Pour la question sur la consommation des applis d'aggrégation de contenus c'était une question subsidiaire, sans forcément de rapport avec le protocole utilisé. C'est le cas d'utilisation cité par Awake qui m'y a fait pensé.

[GrandFather]

J'ai regardé Mercure c'est vraiment sortir le bazooka pour tuer une mouche, le protocol est tellement simple à la base

Le protocole de notification en lui-même est effectivement assez simple, du moins côté client. Ce qui est compliqué c'est tout ce qu'il y a autour : l'authentification, l'abonnement/désabonnement, la reconnexion automatique, etc. Mercure rend tout cela assez simple à implémenter.

Okay. Quand ils sont sur leur lieux de travail et connecté à leur intranet du coup? Et j'imagine qu'en cas de déconnexion il y a un reppli vers les mails / SMS.

C'est cela. Mais il n'y a pas de déconnexion, sauf en cas de problème réseau majeur. Et dans ce cas la messagerie d'entreprise ne fonctionne plus, donc...

[tenshu]

J'ai regardé Mercure c'est vraiment sortir le bazooka pour tuer une mouche, le protocol est tellement simple à la base

Bah c'est un "hub" complet avec pleins de features.
C'est comme dire olalala c'est vraiment un bazooka RabbitMQ pour faire du pub/sub.

[Dross]

Yup, surtout si c'est pour ""rester simple"" et redévelopper la roue juste derrière.

[Orhin]

Exactement.
Par exemple sur notre projet actuel, on utilise GraphQL.
Ben on s'est pas emmerdé, on est passé directement sur l'intégration Websocket du client GQL qu'on avait.

[Awake]

Ouais ma réflexion n'était pas bien intelligente. En fait comme toute stack, ça dépend des besoins du projet... des fois une solution complète sera préférable, d'autres fois une implémentation légère sera mieux.

[Fastela]

5% c'est pas cher du tout
De ce que je vois dans mon réseau c'est plutôt 10% voire plus

Si c'est du vrai accompagnement et que tu peux refacturer, je pense qu'il ne faut pas trop réfléchir.

Merci pour le conseil Tenshu. Ça m'a donné confiance pour gonfler un peu mon TJM histoire d'absorber ce cut. Le rdv avec le client s'est super bien passé, et même si c'était des technos que je maîtrise pas très bien (API Platform, Nuxt), j'étais bien hypé par le projet. Mais finalement, douche froide pour tout le monde, le client final a pris la décision de geler tous les devs pour l'été, donc ma mission devient caduque.

Ça fait 5 mois que je suis en galère et que j'arrive pas à trouver de mission, ça commence à devenir méga relou cette situation.

[Awake]

Juste une piste : mon ESN m'a dit faire parfois proxy pour des freelances : elle trouve les missions, facturent le client et le free refacture à l'ESN derrière. Peut-être contacter les ESN du coin pour voir si elles font ça ?

[Orhin]

Je confirme que c'est relativement courant, mon ancienne ESN le faisait aussi.
Par contre le % retenu est en général un peu plus élevé.

[gros_bidule]

C'est même apprécié de pas mal d'ESN. Ils te paient que ce que tu bosses, et pas d'intercontrat à payer. C'est presque le nirvana pour eux.
Mais le freelance peut y voir son intérêt. Tu te finances et prends tes congés quand tu veux (pas de lien de subordination, tu n'es pas salarié). Et si la mission est naze, tu t'en vas. Ton chargé d'affaires ne pourra pas te demander de faire un "effort" et d'attendre la saint glinglin, qu'il daigne te trouver une autre mission. Garde aussi en tête que tu seras possiblement vendu plus cher (parfois grassement, ou pas. C'est le jeu ^^), donc davantage sur un siège éjectable aux yeux du client. Et biensûr, pas de CE, pas/peu de formations, les prêts bancaires tu oublies, etc.
Bref, c'est un calcul à faire. Perso, j'ai fait mes dernières missions freelance ainsi avant de raccrocher, et ça m'allait très bien, surtout pour annoncer mes congés sans jamais me prendre la tête. Haaa maman, c'était bon ça.

[Fastela]

Encore faut-il trouver une ESN agréable à bosser avec. La dernière avec qui j'ai eu affaire, ça s'est terminé en procès pour licenciement abusif (CDI de chantier, si on vous propose ça fuyez en courant).

[Awake]

Encore faut-il trouver une ESN agréable à bosser avec. La dernière avec qui j'ai eu affaire, ça s'est terminé en procès pour licenciement abusif (CDI de chantier, si on vous propose ça fuyez en courant).

Pour contrebalancer un peu ton expérience, mon ESN actuelle (et première ESN pour moi) est une des boites les plus sympa et réglo avec lesquelles j'ai pu travailler.

Pourtant je suis arrivé avec beaucoup d'à-priori dans cette boîte, vu ce qui se dit en général sur les ESN, mais ils ne rentrent pas du tout dans les stéréotypes. Et ce n'est pas parce que je suis dev senior qui leur rapport plein de brouzoufs, la jeune BA qui n'a aucune expérience et qui est restée 5 mois en intercontrat est traitée avec autant d'égards.

[Awake]

Petit retex, j'ai implémenté de l'échange temps réel un peu velu entre :
- une application mobile avec une webview qui se connecte en Server Sent Events sur une app express pour écouter, et qui envoie des données via du fetch POST classique
- un serveur websocket pour du jeu en temps réel sous node

Ce beau monde est connecté via des events. J'ai fait une implémentation fonctionnele en RabbitMQ, jusqu'à ce que je tombe sur un comparatif avec Redis. J'avais oublié que Redis pouvais faire du pub/sub , et le fonctionnement est plus adapté que rabbit, sans parler que j'ai déjà du Redis sur ma stack. Bref j'ai tout refait sous Redis, et faut bien dire que c'est beaucoup, beaucoup plus simple à mettre en place que rabbit.

Ça marche nickel

Depuis le websocket, une action du client publie l'event redis, qui est écouté par l'app express, et dispatchée dans le bon SSE si nécessaire, qui est écoutée par l'app mobile.

Depuis l'app mobile, on envoie une requête POST sur un endpoint, qui publie l'event redis, qui est écouté sur le serveur node websocket, qui redispatch aux bons clients connectés !

Plus qu'à voir à quel point il y a des fuites mémoire (j'ai fait gaffe cela dit).

En tout cas je suis assez fier de ma solution, c'est léger, robuste, et ça peut scale.

[gros_bidule]

Justement, les ESN, je crois qu'elles essaient d'être ta meilleure amie du monde de la terre tant que tu leur rapportes du pognon et que tu ne poses pas trop de soucis.
Dès que tu es moins intéressant, le ton peut vite changer. Et cela vaut tant pour un débutant qu'un sénior, jeune ou vieux, homme ou femme, beau ou moche.
Il existe probablement des exceptions, comme tout, fort heureusement. Mais généralement, quand je lis : je rapporte des sous + mon ESN me traite bien... enfin bref, z'avez compris.

[Awake]

Ouais enfin bon je dis le contraire dans mon post.

Après c'est possible que je sois très bien tombé.

[Awake]

J'ai pas trop creusé mais quelques infos qui sortent du leak de la recherche Google :
- les clics ont un poids
- le nombre d'utilisateur sous chrome a un poids
- il y a un des ajustements de poids manuels, faits par des humains

Donner plus de poids à chrome est probablement pas super légal, en Europe au moins..

[tompalmer]

Le leak est pas authentifié encore je crois

[yuushiro]

Hello les canards codeurs.

Peut-être que certains d'entre vous ont été confrontés au même problème que celui que je rencontre.

J'ai plusieurs applications Angular2+ (avec des versions hétérogènes - on va dire de la 11 à la 15).
L'idée c'est que j'aimerai bien regrouper toutes ces applications au travers d'un petit portail unique mais à moindre frais.
En cherchant, je suis tombé sur plusieurs framework / technos : bit.dev, single-spa.js.org et du webpack / module federation.

J'ai l'impression que les 3 produits peuvent répondre à mon besoin.

Après lecture, je vois que single-spa permet de mixer les technos (si j'ai une appli en react par exemple je pourrais l'intégrer aussi au portail).

Bit.dev ne permet pas de mixer les technos (j'ai l'impression que tout doit être dans un unique framework - même version)

Pour webpack / federation module, c'est pas très clair non plus.
De ce que j'ai pu saisir, c'est que toute l'application qui est build via webpack doit être dans la même techno et version, mais que l'on peut ensuite charger des builds webpack dans le portail peut-importe les technos de chaque build.
Par contre, ça à l'air un petit plus simple de mise en œuvre et ça évite d'être dépendant d'un autre framework.

Pour la communication inter-applicatif, j’hésite à passer directement par du eventDispatcher et du addEventListener ou d'utiliser une librairie d'eventBus.

Est-ce que vous avez déjà utilisé ça ? Vous me conseilleriez de m'orienter plus vers quelle solution ?

Merci pour vos conseils.

[Awake]

Si je comprend bien tu veux fusionner des applications distincts dans une seule et même application.

Je suppose que l'option "une page html d'accueil qui redirige sur chaque app" n'est pas jouable ?

Je t'avoue que je n'avais jamais entendu parler de ça, et déjà qu'une seule app angular/react peut-être difficile à maintenir, mais en faire vivre plusieurs en // comme ça, ça me semble plus que complexe. Mais peut-être que je me trompe.

[Awake]

Petit retex sur le dev d'une app mobile pour ma plateforme de jeux de rôle : comme la stack des autres projets de la société était déjà en TS, je suis parti sur react native + ts. J'ai réussi à en faire plus ou moins ce que je voulais, mais au bout de quelques mois, je me suis rendu compte que j'avais besoin de gagner le plus de temps possible sur tout ce qui n'est pas le coeur de l'application, donc je suis parti sur les services suivants :
- expo + EAS, qui gère les builds et les dépendances du projet, avec l'ambition de ne jamais "éjecter" (n'utiliser que des plugins compatibles)
- revenuecat pour les achats in-app et plus tard les abos, pour simplifier le workflow d'achat
- posthog pour l'analytics (serveurs EU, anonymisation de l'ip)

Ça fait bien le taf avec peu d'efforts.

J'utilise pas mal les webviews, souvent par nécessité, et ça marche bien mais il faut avouer que la communication entre react native et les webviews est vraiment primitive, même si on peut tout faire.

Mes impressions sur les services :
- React Native marche très bien
- Expo m'a fait gagner un temps fou, je recommande vraiment. EAS aussi, ça marche tres bien et les tarifs sont ok
- Le Play Store c'est plus du tout open bar comme au début, ça m'a pris un temps fou de tout configurer et montrer patte blanche. J'ai pu faire une bêta fermée de quelques semaines, puis lancer en accès anticipé hier
- Je n'ai pas encore lancée l'app sur l'App Store (parce qu'il me faut un mac pour au moins tester, même si je pourrais build "à l'aveugle" avec expo EAS), mais je sens que ça va être du boulot aussi
- Posthog, je n'ai pas trop de recul pour l'instant, pour le moment rien à redire (les events s'accumulent vite, leur offre à 1m d'events gratuits n'est pas si généreuse que ça ^^)
- Revenue cat marche bien, pareil pour le moment pas assez de recul. Les endpoint serveur sont particulièrement faciles à mettre en place.

Globalement une tres bonne expérience de développement, et pour le moment les feedback sont excellents sur l'app.

Je sais pas si ça vous intéresse vraiment ce genre de retours, moi j'aimerais bien en lire plus de la part des canards.

[war-p]

Tien, petite question sur ta stack d'appli mobile, je suis pas dev front et/ou mobile (sauf quand je suis obligé, je suis bavkend/devops), tu utilises react native, là où je bosse ça n'a pas l'air de faire l'unanimité. Du coup je voulais savoir comment t'avais architecturé ton projet.

[Awake]

Je pense avoir utilisé une archi très commune :
- la navigation/routage des vues se fait via expo router https://docs.expo.dev/router/introduction/
- un répertoire pour les composants react utilisés dans les vues
- un répertoire pour les hooks react
- un repertoire pour les services : je ne suis pas parti sur une lib d'injection de dépendance, j'ai juste fait une classe par service et une instance globale de chaque.
- un repertoire pour les types ts
- la configuration est faite dans un .env (c'est géré nativement dans expo)

L'idée est que les vues react soient le plus simple possible et fassent ce qu'elles doivent faire : de l'ui reactive. La majorité du métier est déporté dans les services.

Je n'utilise pas de store redux ou autre, en revanche, une evolution que je vais peut-être faire sera d'avoir des signaux preact (des variables reactives globales) pour éviter d'avoir des contextes react qui sont lourds à gérer https://preactjs.com/blog/introducing-signals/

Rien d'extraordinaire donc, j'espère que ça répond à ta question

[war-p]

Yep, le truc de l'injection de dépendances, c'est le premier grief que j'entends le plus souvent. Ça et la mauvaise utilisation du redux

[Etheon]

Je profite de la discussion sur les app mobile pour donner des nouvelles de notre projet de boite dont j'avais rapidement parlé ici.

Après plus de 7 mois de développement en solo, j'accouche d'un beau bébé avec:

• Une application mobile iOS/Android | Techno Flutter (j'ai adoré bosser avec Dart)
• Une base de données postgres custom (Avec sqitch pour gérer les évolutions) | Techno SQL
• Un backend Node.js qui gère la communication avec la DB et quelques autres services (notamment le système de mail avec Listmonk)
• Un backoffice "homemade" qui permet de gérer les utilisateurs, mais surtout les circuits de l'application et tous les éléments annexes (glossaire, récompenses...) | Techno Sveltekit
• Un frontend très très basique, avec une page d'accueil, un formulaire de contact, et un système de blog (accessible aussi dans l'app) | Techno Sveltekit

C'était éprouvant, mais ultra enrichissant. J'ai commencé l'app en décembre avec apprentissage de flutter (Avec ce cours Flutter vraiment pas mal si ça intéresse du monde https://www.youtube.com/watch?v=IfUj...ILtRAgd3h2CNpT). Aujourd'hui je me sens beaucoup plus à l'aise avec cette techno et ça me rassure sur les évolutions de notre application.
Pour le reste, et surtout la base de données, les connaissances acquises pendant mon bootcamp O'clock on fait la diff (sinon je serais parti sur un truc genre Directus + un ORM lambda et j'aurais pas pu faire un truc aussi spécifique à nos besoins).

Je pense écrire un ou quelques articles sur le sujet, au moins pour moi et pour mettre sur papier cette expérience, je reviendrais ici quand ce sera fait (faut que je trouve le temps...).

Si je retiens UN truc, c'est que je hais faire du frontend web , même si Sveltekit c'est très cool, c'est la ou je me suis le moins éclaté. Je me sens définitivement dev backend. Je précise bien "web", parce qu'utiliser Flutter pour faire des interfaces mobiles c'est un régal . Je me suis rarement battu avec le langage / framework, c'était très très fluide (alors que j'avais 0 xp).

Voili voilou, si vous avez des questions hésitez pas ! Et si vous voulez jeter un oeil au projet:
Le site officiel (Qui va se remplir semaine pro et avec un design update vu qu'on a déjà fait évolué 2 fois la DA)
L'application sur iOS et sur Android

[Awake]

L'app a l'air canon sur les screens play store ! D'un point de vue tech en tout cas. Le design fait très enfantin à mon goût (mais c'est surement voulu).

Qu'est ce que tu entends par "Une base de données postgres custom" ?

Tu as fait ton backend node avec quoi ? Si je devais choisir un techno node.js je partirais sur du nestjs de nos jours.

Merci pour ton retour sur Flutter, j'en entends beaucoup de bien un peu partout.

[Etheon]

Ouais pour la DA on a choisi un style mignon qui pourrait plaire aux plus jeunes, l'idée étant de viser un public familial. On va attendre les premiers retours et rectifier si nécessaire !

Pour la BDD postgres, custom dans le sens tout fait à la main. Pas de supabase et autre (que j'adore mais pour le coup on voulait vraiment avoir un truc from scratch), j'ai des fonctions qui font 300 lignes de SQL mais par contre c'est ultra ciblé sur ce qu'on a besoin. Ce qui fait que côté backend c'est plutôt simple, j'ai juste à appeler mes fonctions, pas d'ORM et de requêtes à ralonge.

Le backend, c'est du express.js bien old school mais qui marche et on était sur que ce soit production ready. Si je me relançais dans un projet ET que je devais rester dans du JS, j'irais plutôt vers AdonisJS qui a sorti sa dernière version début d'année. J'ai bien envie de le tester sur des projets perso.
Mais rétrospectivement, si je devais faire un nouveau backend, je choisirais juste pas JS.

Tout l'environnement de dev, le DX est horrible. Je vais peut être pas me faire d'amis mais pour moi Typescript c'est un pansement, c'est la plaie à configurer (et vas-y que j'installe eslint-typescript, eslint-bidule, et puis aussi prettier pour la mise en forme, ah et pi tient il manque un truc dans le tsconfig.json parce que pas compatible avec le package moncul...). J'ai commencé le dev web ya maintenant 5 ans sur mon temps libre, et j'avais un peu qu'un seul point de repère vu que j'avais que fait du JS.
Après avoir touché à Flutter/Dart, niveau expérience développeur c'est quand même le jour et la nuit. Tout marche de suite, j'ai peut être 2 plugins vscode pour l'ensemble (contre trouzmille pour JS), et tout est clair, les messages d'erreurs limpides, bref le monde du développement web il est pas simple en fait.

Du coup, et pour avoir commencé à étudier un peu le truc, si je devais refaire un backend aujourd'hui, ce serait C# et ASP .net core !

[Awake]

Sympa Adonis, je connaissais pas. Pour avoir fait pas mal de java récemment, ça a été un soulagement de revenir sur du express/ts pour un projet pro niveau DX.

j'ai des fonctions qui font 300 lignes de SQL

Tu as un exemple du genre de manipulation qui nécessite une fonction pareille ?

[Etheon]

Sans trop rentrer dans le détail de l'architecture de la BDD, on a une table "circuit", qui contient les parcours, mais qui a énormément de liens sur d'autres tables via des tables de liaisons.

On a une table pour les niveaux de difficulté, on a une table pour les thèmes (par exemple architecture, nature etc...), on a une table pour les villes... et plusieurs autres. On ne répète pas des infos qui peuvent être dans une table, mais du coup ben derrière ça complexifie parfois les appels ^^ Celle qui fait environs 300 lignes (240 en vrai, j'ai exagéré !) c'est la fonction d'update d'un circuit utilisé dans mon backoffice. Elle va mettre à jour le circuit, l'ensemble des éléments des tables liées, et les traductions.

Un autre élément, j'ai géré la localisation des textes dans la BDD également. J'ai donc une table translation qui va contenir une clé de traduction, sa langue, et le texte traduit. Dans la table circuit, au lieu d'avoir le nom, j'aurais sa clé de traduction du genre "circuit_1_name". Lorsque je vais aller chercher les informations dans la BDD, je vais faire un remplacement de la clé par sa traduction, en fonction de la langue demandée.

La combinaison de ces deux facteurs (beaucoup de liaisons + gestion de la traduction) fait qu'on arrive à des grosses fonctions ^^

Par contre, l'avantage de notre app c'est que la table circuit ne change que rarement (on va pas rajouter des circuits tous les jours). J'ai donc utilisé les vues matérialisées afin de pouvoir enregistrer les circuits en anglais et en français. Ca permet un appel en lecture ultra rapide de la totalité des circuits. J'ai un petit job cron qui va mettre à jour régulièrement ces vues. J'ai aussi une petite fonction qui force la réactualisation si nécessaire.

[Orhin]

Pour eslint/prettier, je recommande de passer à Biome à la place.
Ça remplace les 2 outils, c'est 20x plus rapide et la configuration par défaut est très bien.