Du SQL sur un fichier YAML : pourquoi nous avons écrit Memless en Rust

Le problème des jeux de test

Les données de test vivent souvent dans un endroit que personne ne relit : un script d’insertion, une base partagée, un fichier JSON illisible. Nous voulions l’inverse — des données qu’on lit, qu’on relit et qu’on compare dans Git, comme le reste du code.

Memless charge un fichier YAML en mémoire, accepte du SQL ordinaire, et réécrit dans le fichier chaque modification acceptée. Il est fait pour les jeux de test et les démonstrations, pas pour la production.

Aucun schéma à déclarer

Memless lit la structure dans les données elles-mêmes : le type des valeurs, l’identité des lignes et les relations entre tables. Une colonne nommée user_id pointe vers users.id, sans rien déclarer.

users:
  - id: 1
    name: Ada
  - id: 2
    name: Grace
wallets:
  - id: w1
    user_id: 2 # pointe vers users.id = 2
    amount: 100

const { load } = require('@nascent-tech/memless');
 
const db = load('data.yaml');
db.query('SELECT users.name, wallets.amount FROM wallets INNER JOIN users ON wallets.user_id = users.id');
// { columns: ['users.name', 'wallets.amount'], rows: [['Grace', 100]] }
 
db.execute("UPDATE wallets SET amount = 150 WHERE id = 'w1'"); // data.yaml est réécrit
db.release();

Un cœur, trois langages

Nos équipes écrivent leurs tests en PHP, en Go et en Node.js. Plutôt que trois implémentations qui divergent, Memless a un seul cœur en Rust, exposé à chaque langage. Le même fichier et la même requête donnent le même résultat — et le même message d’erreur — partout.

Ce que Memless n’est pas

Memless tient en mémoire et réécrit un fichier : ce n’est ni une base de données de production, ni un outil pour de gros volumes. Sa documentation dit précisément quand ne pas l’utiliser, et nous tenons à ce que cette page reste aussi visible que les autres.

La documentation complète est en ligne sur memless.nascent-tech.co.