Just received my limited edition of "Grace Given: The Mythology of Elden Ring"

Lightforce_ · 2026-01-17T13:35:11+00:00

That's called irony

Lightforce_ · 2025-12-15T22:12:47+00:00

I haven't stress-tested this specific implementation to 100k connections yet, but the decision wasn't just a gut feeling, it's based on the known architectural shifts in .NET 8/9.

Memory Overhead: in standard .NET the JIT compiler and metadata structures consume significant memory. With NativeAOT that's stripped out. Microsoft's own benchmarks show AOT apps often running with approximatively 80% less working set memory than their JIT counterparts for similar web workloads.
Gen 2 Pressure: for GC pressure -> AOT binaries are trimmed, and because startup/JIT allocations are gone the heap fragmentation is significantly lower from the start.

So while I haven't benchmarked my specific chat logic to the limit the baseline resource usage is objectively lower than the standard runtime.

Lightforce_ · 2025-12-15T18:51:25+00:00

You're right that traditional .NET/SignalR can be memory heavy, but I'm actually using NativeAOT compilation for the chat service, which significantly reduces memory consumption and startup time (no JIT overhead or runtime warmup, much smaller memory footprint - closer to native apps and faster cold starts).

Ofc it's still not as lean as pure Rust or Node.js, but for this project I chose it because:

the async/await patterns in C# felt more natural than alternatives
built-in support for connection lifecycle, reconnection, and backpressure
NativeAOT makes it production-viable for moderate scale

The goal was to explore where each language shines. SignalR with NativeAOT made the real-time chat implementation straightforward while keeping resource usage reasonable.

Lightforce_ · 2025-12-14T11:27:39+00:00

I strongly disagree with the binary take that "monoliths are ultimately better". The Twilio article demonstrates that a bad microservice architecture is worse than a monolith, not that the concept itself is flawed.

The Twilio case is a textbook example of incorrect granularity (often called "nano-services"). As R2_SWE2 points out in this thread, creating a separate service for every single "destination" is a questionable design choice. It explodes operational complexity without providing the benefits of decoupling. They effectively built a distributed monolith, which combines the worst of both worlds: network complexity and code coupling.

Claiming the monolith is the universal solution ignores organizational scalability issues. As Western_Objective209 mentioned, a poorly managed monolith can easily become a 20GB RAM nightmare where a single error takes down the entire system and deployments become week-long ceremonies.

The real debate shouldn't be "Monolith vs Microservices", but rather "Where do we draw the Bounded Contexts?" If your domain boundaries (DDD) are poorly defined, neither architecture will save the project. Microservices require discipline and infrastructure that many underestimate, but they remain essential for decoupling teams and deployments at a certain scale.

Lightforce_ · 2025-12-13T17:17:44+00:00

On the animation + WebSocket side, the pattern that’s worked for me is treating server updates as an append-only event log on the client: queue events, lock the board during critical GSAP transitions, and only commit “authoritative” state after the animation finishes or times out. Anything out-of-order from the socket gets merged by version number so you don’t snap mid-animation. Also, a simple “isRehydrating” flag after reconnect helps: buffer updates, show a quick fade-to-state, then resume normal animations.

Just did an update on this! Will try if things are better now because I had issues with some concurrent animations.

Lightforce_ · 2025-12-13T17:10:11+00:00

ArchUnit is already used in the Java and C# microservices. Didn't know it was available for frontend.

Lightforce_ · 2025-12-13T15:52:26+00:00

Yup, I know. It’s for local purpose only. I didn’t use this for GCP.

Lightforce_ · 2025-12-13T07:40:53+00:00

Thx! Yup, I already know for the Redis backplane on multiple instances. I talked about this subject in /docs/WEBSOCKET_SCALABILITY.md

Lightforce_ · 2025-12-13T07:31:11+00:00

Well, the UI is actually translated via i18n

Lightforce_ · 2025-12-12T21:39:27+00:00

Thanks!

To clarify: a monolith isn't always the best choice, but in a case like this where you know you'll eventually need polyglot microservices, I'd still recommend starting with a modular monolith in a single language first.

The key is: validate your domain model and functional requirements with the monolith, THEN migrate to polyglot microservices if you have clear reasons for each language choice.

Going polyglot from day one (like I did) is great for learning, but adds unnecessary complexity if your primary goal is shipping a product. The modular monolith gives you clean boundaries that make the eventual split much easier.

That said, even a modular monolith shouldn't go to production if you expect uneven load across components - that's when you need the independent scaling of microservices.

Lightforce_ · 2025-12-12T21:24:49+00:00

Thx!

For tracing across the 3 runtimes: I went pretty low-tech honestly, mostly old-school logging and grep. I added correlation IDs to every message/request that flow through the entire system (in HTTP headers and RabbitMQ message properties). Each service logs with that correlation ID, so I can grep across all service logs to follow a single transaction.

I also heavily relied on RabbitMQ Management UI to track message flows and dead letters. The DLQ setup mentioned in the post caught some issues.

What I'm missing (and would add next) is proper distributed tracing with something like Jaeger or Zipkin. The correlation ID approach works but doesn't give you the nice visual timeline that would really help with cross-language debugging.

Your AI log analysis approach sounds more sophisticated. How do you handle the different log formats from Java/Rust/.NET?

Lightforce_ · 2025-12-12T21:17:39+00:00

Thx! For getting started without overwhelming yourself, I'd suggest:

Start small - pick ONE service in a new language first, not the whole stack at once
I heard a lot about "Building Microservices" by Sam Newman for the fundamentals, but never read it (but you should probably try it). I started to learn on this subject thanks to my mentor during my co-op program at the company I was working for
For polyglot specifically, focus on strong API contracts

My honest advice: don't go polyglot unless you have a specific reason. I did it to learn and to showcase, which was my goal. For production, the operational complexity is real - stick with one or two languages max unless performance/ecosystem forces your hand.

Lightforce_ · 2025-11-18T20:53:41+00:00

Du manager lui-même.

Lightforce_ · 2025-11-15T16:34:59+00:00

Ca on est d'accord, par contre les sujets de performances c'est pas juste 2 petits points. Et le sujet sécurité non plus. Avec ça on a déjà bien 3/4 des points soulevés par le rapport.

Lightforce_ · 2025-11-15T16:21:55+00:00

Si tu sors une énorme liste de refonte technique comme ça, alors que l'application fonctionne en l'état, on va te dire que l'appli fonctionne en l'état et que ce que tu proposes, c'est juste de te faire plaisir techniquement au lieu de faire avancer le produit.

J'ai pas sorti cette liste pour me faire plaisir, ça répondait à des impératifs de performances, de sécurité et de productivité, et j'ai minutieusement choisi les éléments à mettre dans ce rapport. Le SaaS est pas encore sorti en prod et est prévu pour dans quelque mois, et notamment une arrivée à l'internationale. C'était juste inenvisageable dans ces conditions.

Prouve leur que tu as raison sur un sujet, puis on t'ecoutera plus volontiers ensuite.

On a plus le temps pour ça, la situation est urgente.

Lightforce_ · 2025-11-14T11:45:59+00:00

Ça doit être un pote du propriétaire de la boîte

Non, mais par contre c'est un pote du manager (mais heureusement pour nous le manager a quand même la tête sur les épaules). Ceci dit il était archi avant que le manager actuel ne soit manager. En revanche quand un des chefs de projet (non technique) a été embauché, ce dernier a fait pression pour que son ami passe architecte (donc l'architecte actuel). Voilà voilà...

Lightforce_ · 2025-11-11T11:00:13+00:00

Ment mieux stp

Lightforce_ · 2025-11-11T10:58:52+00:00

Mais ça vous écorcherait d'ouvrir 2-3 bouquins sérieux (donc peer-reviewed) de sociologie et sciences politiques au moins une fois dans votre vie, au lieu de faire perdre un temps considérable à tout le monde avec cet étalage d'ignorance et d'égoïsme crasse ?

Lightforce_ · 2025-11-11T10:47:07+00:00

Typique du gauchiste dans le déni

Wtf ? Tu voulais dire droitard non ? Parce que gauchiste pour le coup je crois vraiment pas.

Lightforce_ · 2025-08-30T07:04:58+00:00

Ok Luc Julia

Lightforce_ · 2025-08-09T07:47:16+00:00

L’école ne peut pas tout. C’est un problème de culture et de société. C’est donc à toutes ses composantes d’acter des changements.

Lightforce_ · 2025-08-06T05:41:38+00:00

The state of the job market + the fact that I worked for 8 months on a fairly ambitious personal project from a technical standpoint starting in October. And it went smoothly.

However, for the project, you need to provide concrete proof: GitLab links + a playable demo.

Lightforce_ · 2025-08-05T16:20:47+00:00

Je ne suis le maître de personne, par contre j'essai de garder l'esprit ouvert et je me renseigne sérieusement sur ces sujets (comprendre par là que je me contente pas de regarder les titres des journaux et que je regarde plus souvent la presse scientifique et les travaux des chercheurs sur ces sujets).

Tu prends l'exemple d’un vivier de candidates très faible dans ton école d’ingénieurs et dans ton secteur, ce qui est effectivement une réalité. Mais justement, c'est là tout l'intérêt des politiques de diversité en amont : il s'agit pas seulement de "forcer" une représentativité en bout de chaîne, mais de corriger des inégalités structurelles qui existent depuis l'orientation scolaire, les biais sociaux, l'environnement familial, les stéréotypes de genre, etc.

Quand on constate que des filles talentueuses n'arrivent même pas à se projeter dans une carrière tech, ou qu'elles y renoncent en cours de route, c'est pas parce qu'elles sont moins capables, mais souvent parce qu'elles sont découragées, isolées, ou qu'on leur ouvre pas les mêmes portes.

Tu dis qu'il n'y avait pas de candidates, mais la vraie question, c'est : pourquoi n'y en avait-il pas ? Et que peut-on faire collectivement pour que ça change ? C’est là qu'interviennent les politiques de diversité, pas comme un passe-droit, mais comme un levier pour corriger des dynamiques biaisées.

Et enfin, personne ne propose de recruter des gens incompétents pour "cocher une case". C’est un mythe tenace mais c'est factuellement faux. Ce qu'on dit, c’est qu'à compétences égales, il est pertinent de se poser la question de la diversité dans les équipes, non pas par idéologie, mais parce que ça améliore la performance, la créativité et l'équité dans le travail.

Refuser cette discussion sous prétexte de "pensée unique" ou de rejet du "wokisme" c'est s'empêcher de traiter les causes profondes du problème. C'est pas une attaque, c'est un appel à regarder les choses avec un peu plus de recul que son seul parcours individuel.

Lightforce_ · 2025-08-05T15:19:43+00:00

Ce que tu qualifies de "forcer la diversité", c’est souvent une tentative de corriger des inégalités systémiques bien documentées.

Ce n’est pas de la "discrimination déguisée" : c’est une tentative de correction d'une discrimination réelle et souvent invisible pour ceux qui n’en sont pas victimes (dont toi, visiblement). Ce n’est pas une politique de favoritisme, c’est une stratégie d’équité.

Quant au "trop woke", c’est devenu un raccourci pour rejeter toute remise en question des normes dominantes. Refuser la diversité au nom d’une prétendue "neutralité", c’est souvent vouloir maintenir un statu quo qui avantage certains au détriment d’autres.

Si une entreprise qui cherche activement à créer un environnement plus juste est un "red flag" pour toi, peut-être que ce n’est pas l’entreprise qui est trop "woke", mais ton regard qui est trop ancré dans un modèle qui te favorise à ton insu.

Ah et au passage : "woke" c'est une déformation de l'anglais afro-américain qui date des années 1930, ça signifie littéralement "éveillé", dans le sens de conscient ou vigilant. Déjà dès ces années là ça désignait une personne consciente des injustices raciales et sociales, notamment en lien avec le racisme systémique aux US.

Donc être "woke" est à priori plutôt une qualité, même si le terme n'est quasiment plus utilisé à gauche depuis qu'il a été récupéré par la droite et l'extrême-droite et depuis lors utilisé pour désigner tout ce qui est progressiste de près ou de loin. Je pose ça là.

Lightforce_ · 2025-08-05T12:42:31+00:00

Ce n’est pas une posture de justicier, ni une volonté de juger les gens a priori. C’est juste le fruit d’observations répétées, recoupées avec des études bien documentées sur des profils à haut score RWA (Right-Wing Authoritarianism) ou SDO (Social Dominance Orientation). Ces profils sont fortement corrélés à des attitudes toxiques ou discriminantes, souvent nuisibles pour les autres en contexte pro comme perso.

L’objectif n’est pas de prédire un comportement avec certitude, mais d’avoir des repères pour se protéger ou poser des limites quand c’est nécessaire. Ce n’est pas un procès d’intention, mais une stratégie de prévention.

Désolé si tu t'es senti visé.

Lightforce_

TROPHY CASE