Some notes on Local-First Development, “Agile with ‘Idiots’”, Being Glue
The web feels ready for a major upgrade. We had tightly coupled web frameworks in the Rails/Django years and lost them with the shift to API-powered SPAs. The developing database-grade sync technology will tightly recouple our application stacks allowing for a new era of framework innovation.
I see “local-first” as shifting reads and writes to an embedded database in each client via“sync engines” that facilitate data exchange between clients and servers. Applications like Figma and Linear pioneered this approach, but it’s becoming increasingly easy to do. The benefits are multiple:
- Simplified state management for developers
- Built-in support for real-time sync, offline usage, and multiplayer collaborative features
- Faster (60 FPS) CRUD
- More robust applications for end-users
[…]
To fully replace client-server APIs, sync engines need robust support for fine-grained access control and complex write validation.
The most basic use case for an API is state transfer from the server to the client. The client wants to show information about an object so reads the necessary data through the API.
Local-first tools all handle this perfectly. They ensure the latest object data is synced correctly to the client db for querying from the UI.
But while reads are generally easy, support for complex writes is still immature in local-first tooling. Clients tend to have unrestricted write access and updates are immediately synced to other clients. While this is generally fine for text collaboration or multiplayer drawing, this wouldn’t work for a typical ecommerce or SaaS application.
[…]
But in general, I’d still be wary of using local-first outside real-time / multiplayer / offline use cases. Local-first is definitely still bleeding-edge. You will hit unexpected problems. A good community has rapidly developed, but there’ll still be some stretches on the road where you’ll have to solve novel problems.
Un article de taille moyenne/longue sur le paradigme « local-first ». Si comme moi vous n’en aviez pas encore entendu parlé, je vous recommande de le lire ! L’auteur va au déla des use cases actuels et développe sur les limites et territoires inconnus de l’approche. Il cite également quelques technologies intéressantes pour mieux appréhender les possibilités.
Le concept n’étant pas développé au début de l’article, voici un petit marche-pied pour la lecture : plutôt que d’interagir avec des APIs de gestion pour faire fonctionner vos clients web, ceux-ci se reposent sur une BDD locale, et cette dernière se synchronise en arrière plan directement avec une base centrale.
Ce qui est amusant c’est que c’est le type d’approche que j’adopte pour mes projets perso. Le plus gros étant un outil de gestion de cartes avec états temporels (la carte évolue selon l’année sélectionnée) qui permet une synchro entre différents consommateurs (le type de use case partagé dans l’article). Je ne me reposait pas sur un protocole de synchronisation propre à la DB, j’avais tout de même un backend (ne connaissant pas les techno citées dans l’article), mais celui-ci ne connaissait rien du métier : ni la logique, ni les données. Gérer les migrations de données était alors assez particulier, j’en suis même venu à le faire du côté front avec mon propre système d’update (oui j’ai bien dit que c’était particulier ^^´).
Et un autre exemple plus récent et plus simple : l’outil que je me suis fait pour la collection de liens de cette newsletter :)
As IT coaches and consultants, we often have to deal with “idiots” when trying to implement agile in some organisations. “Embrace change!” we say, “For disruption is good” “Talk with each other more!” we say, “For collaboration is good” “Visualise your work!” we say, “For exposure is good” And the idiots won’t. “Let’s try a game!” we say. And the idiots scoff.
Post pas bien long, mais qui fait mouche. La répartition des « adopters » sur la courbe de Bell me fait me demander où nous en sommes aussi nous, les coachs et consultants.
Your job title says "software engineer", but you seem to spend most of your time in meetings. You'd like to have time to code, but nobody else is onboarding the junior engineers, updating the roadmap, talking to the users, noticing the things that got dropped, asking questions on design documents, and making sure that everyone's going roughly in the same direction. If you stop doing those things, the team won't be as successful. But now someone's suggesting that you might be happier in a less technical role. If this describes you, congratulations: you're the glue. If it's not, have you thought about who is filling this role on your team?
Every senior person in an organisation should be aware of the less glamorous - and often less-promotable - work that needs to happen to make a team successful. Managed deliberately, glue work demonstrates and builds strong technical leadership skills. Left unconscious, it can be career limiting. It can push people into less technical roles and even out of the industry.
Retranscription d'un talk sur la nécessaire posture de "glue" que prennent certaines personnes, et des problèmes que cela peut leur poser dans leur carrière.
Attention réflexion tout haut bien personnelle, mais je crois connaître des gens qui se posent les mêmes questions : je crains de tomber dans cette ornière depuis un moment. Si j’ai bien compris une chose sur mon approche au travail c’est que je n’arrive pas me contenter du rôle qu’on me donne : je me pose toujours la question de l’intégration des tâches et responsabilités de mon rôle (indépendamment de ma personne) au sein du tout dans lequel j’agis. C’était le cas durant mon stage d’observation de 3eme, et ça m’a permis de décrocher un job d’été sur plusieurs années. C’était le cas lors de mon stage de première année d’études, et ça m’a permis de jeter ma tâche initiale en Windev (qui n’aurait servi à rien) et de faire du C embarqué pour le département de R&D. C’était le cas de mon premier boulot, et ça a permis au moins pour un temps d’améliorer les relations entre dev et run. C’était le cas lors de nombreuses missions, et ça m’a valu la confiance de plusieurs clients, un burnout, d’appartenir à une équipe de marginaux génialissimes et d’autres situations où je dépassais les limites du contexte en flirtant avec les miennes. « Pour me préserver », j’ai entendu plusieurs fois le conseil de « prendre du recul » , ou encore « si tu ne peux pas changer les choses, change toi toi-même », mais ce que les gens ne semblent pas saisir c’est qu’il ne s’agit pas d’un moyen dont j’userais pour accomplir mon travail, mais de la façon dont je perçois le monde. Si je pense que le monde tournerait mieux en se parlant, en s’inquiétant des impacts de ses actes au delà de notre périmètre, alors lâcher prise sur tout cela reviendrait à devenir ce que je critique. Ce ne serait pas seulement malhonnête, ça me rongerait. Mais de fait, en persistant à me poser des questions aux frontières plutôt que sur une spécialité, je crains de me retrouver dans un cul de sac inqualifiable pour les frameworks d’entreprise.
