Clem

Skurt Cobain

@ledevnovice On cherche des contributeurs sur le projet nodesecure github.com/NodeSecure C’est plutôt accessible et y’en à pour tout les goûts frontend, backend , low level(analyze de code) et securité 🙂

Pas facile d'entrer dans le monde de l'open source. J'essaie de contribuer a un projet que j'affectionne, Tanstack Query, tout en continuant a approfondir ma compréhension d'un point de vue utilisateur et de la techno sous le capot.

@housecor Yes I use optimistic concurrency whenever I can jamesmichaelhickey.com/optimistic-con…

A bug I see in nearly every web app: Last in wins. Bug: If two users are editing the same record, the user who clicks save last “wins”. The last save overwrites the previous save. Two solutions to consider: 1. Notify. Notify me when another user starts editing the record I'm editing. “Warning: Bob is editing this record.” And notify me when I try to save a stale record. “Bob changed this record.” When this conflict occurs, I can copy my changes, reload, and integrate my changes into the latest version. Or, I can just paste my changes over the previous edit if mine should "win". 2. Lock the record. When someone starts an edit, disallow others from starting an edit. "Bob is editing this record." Time out the edit and remove the lock if it's not completed in x minutes. Anyone have a different approach?

@ledevnovice La plupart des gens le voit comme un state manager mais c’est plus secondaire finalement, redux à choisit d’être un state manager pour pouvoir faire de l’event-driven

@ledevnovice Bref le plus gros avantage reste le côté évent-driven tu peux te retrouver avec beaucoup moins de code , et du code plus maintenable que quand tu fais de l’impératif, si tu n’utilises pas redux comme ça ça vaut pas le coup je trouves

C'est quoi les arguments qui vous font pencher vers les solutions comme Redux ou autre dans vos applications React les ami(e)s codeurs ? J'avoue moi je fais toujours sans pour l'instant mais je comprend peut être pas ce que je rate ? ... 👀

@housecor I create a function that handles the backend business logic and call it in the react server component

Scenario: You’re using React Server Components, so you can query the DB in a server component. Your app is the DB’s only consumer. Do you query the DB directly? Or do you still build an HTTP API in front of the DB?

@jamesqquick ORM for the write part and raw sql for the query part

What's your favorite way to work with a database? - raw sql? - ORM (prisma, drizzle, etc.)? - custom product SDK?

@ledevnovice Yes IDDD de Vaughn Vernon le « Red book » j’ai du le lire deux fois pour comprendre toutes les subtilités

Vous aussi vous êtes du genre à relire plusieurs fois certains ouvrages ou lecture tech. Moi perso ca fait plusieurs fois que je me relis "Architectural Styles and the Design of Network-based Software Architectures" de Roy Fielding pour bien en comprendre les idées de REST.

@opposablecrumbs @CFDevelop My entire unit test suites yes , not the integration and end2end ones. And yes I do it on every changes because my unit tests suites run under 1 second

@Clemgbld_ @CFDevelop TDD means you run the entire test suite on every change?

Unpopular opinion: your tests should hit the database

@opposablecrumbs @CFDevelop Doing TDD so I run my tests very often

@Clemgbld_ @CFDevelop why would you possibly need to run the entire test suite every 60 seconds?

@IsraelAlagbe @CFDevelop I test the logic of my db in integration tests in the repositories (secondary adapters in hexagonal architecture), my useCases (application layer in hexagonal architecture) don’t know and do not care if I use sql or mongo db or whatever db you want

@sudokhanh @CFDevelop I write integration tests that interact with the real db on my repositories which are adapters in my architecture. The db is substitute in my useCases tests (where the business logic is )

@CFDevelop @Clemgbld_ Could write a toggler too to keep it as one test except for the DB interaction.

@CFDevelop I write integration test for my repositories that interact with a real db so everything is covered , the db is a substitute in my usecase test (where the business logic is)

@Clemgbld_ Too slow isn't an argument because anything you don't test on your computer, you're kicking the can down the line to the QA team, and testing manually is 10x slower than running it on your computer

@tannerlinsley If there is no SEO requirement I would probably stay dead simple and build a SPA with Vite and React and not bother with SSR. The advantage is that you will be able to reuse most of your code if you want to build a mobile app with RN (if you properly separate logic from UI code)

If I were to start a full stack app today, I would most likely use Remix.