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