Backends TypeScript réactifs : Convex et Pylon changent la donne

En résumé : Au 5 septembre 2026, choisissez Convex pour une expérience TypeScript réactive mature et un cloud managé, ou Pylon pour privilégier l’auto-hébergement, SQLite ou PostgreSQL et une licence permissive. Ma recommandation par défaut va à Convex pour un produit à livrer rapidement ; retenez Pylon lorsque le contrôle de l’infrastructure et de la licence prime.

Une application collaborative traditionnelle assemble souvent une base de données, un serveur API et une couche temps réel. Convex et Pylon réunissent ces responsabilités autour de requêtes TypeScript qui se réexécutent lorsque les données consultées changent. Le gain principal n’est pas seulement la vitesse : c’est la réduction du code de synchronisation à écrire et à maintenir.

Quel problème un backend réactif résout-il ?

Prenons un CRM, un éditeur de documents ou un tableau Kanban partagé. Une architecture classique demande plusieurs mécanismes distincts :

// API REST classique
// 1. Définir le schéma SQL
// 2. Créer les migrations
// 3. Écrire les endpoints CRUD
// 4. Gérer l'authentification
// 5. Ajouter le temps réel
// 6. Invalider les caches
// 7. Synchroniser les types frontend et backend

Chaque raccord peut se désynchroniser. Une mutation réussit, mais le bon événement n’arrive pas au client. Un type évolue côté serveur sans être mis à jour côté interface. Une entrée de cache devient périmée.

Dans un backend réactif, le serveur mémorise les données lues par une requête. Quand une écriture touche ces dépendances, il recalcule le résultat et le pousse aux abonnés. Les documentations de Convex et de Pylon décrivent toutes deux ce modèle.

Comment fonctionne Convex ?

Convex combine une base de données réactive, des fonctions serveur TypeScript et des bibliothèques clientes. Le schéma reste dans le projet :

// convex/schema.ts
import { defineSchema, defineTable } from 'convex/server';
import { v } from 'convex/values';

export default defineSchema({
  tasks: defineTable({
    text: v.string(),
    isCompleted: v.boolean(),
    authorId: v.string(),
  }).index('by_author', ['authorId']),
});

Les lectures passent par des queries et les écritures transactionnelles par des mutations :

// convex/tasks.ts
import { query, mutation } from './_generated/server';
import { v } from 'convex/values';

export const list = query({
  args: { authorId: v.string() },
  handler: async (ctx, args) =>
    ctx.db
      .query('tasks')
      .withIndex('by_author', (q) => q.eq('authorId', args.authorId))
      .order('desc')
      .collect(),
});

export const add = mutation({
  args: { text: v.string(), authorId: v.string() },
  handler: async (ctx, args) => {
    await ctx.db.insert('tasks', {
      text: args.text,
      isCompleted: false,
      authorId: args.authorId,
    });
  },
});

Côté React, useQuery abonne le composant au résultat. Convex suit les dépendances, relance la requête concernée et transmet la nouvelle valeur par WebSocket :

import { useQuery } from 'convex/react';
import { api } from './_generated/api';

function TaskList({ userId }) {
  const tasks = useQuery(api.tasks.list, { authorId: userId });

  if (tasks === undefined) return <Spinner />;
  return (
    <ul>
      {tasks.map((task) => (
        <li key={task._id}>{task.text}</li>
      ))}
    </ul>
  );
}

Quels sont les points forts et les limites de Convex ?

• Typage de bout en bout entre schéma, fonctions et client.
• Mutations transactionnelles avec isolation sérialisable et contrôle de concurrence optimiste.
• Requêtes réactives, recherche plein texte, recherche vectorielle, planification et actions serveur.
• Cloud managé ou auto-hébergement avec le backend open source.
• Licence FSL Apache 2.0 : elle autorise de nombreux usages, mais interdit de créer un produit concurrent du cloud Convex avant la conversion automatique du code en Apache 2.0.

L’auto-hébergement existe officiellement, mais le service managé reste le chemin le plus simple. Votre code applicatif dépend aussi des primitives Convex, ce qui rend une migration vers une base et une API classiques plus coûteuse qu’un simple export de données.

Comment fonctionne Pylon ?

Pylon rassemble la base, l’API, l’authentification, les connexions temps réel et les fonctions TypeScript derrière un serveur Rust. Il utilise SQLite par défaut ou PostgreSQL via DATABASE_URL. Bun exécute les fonctions TypeScript et le rendu React côté serveur.

// apps/api/app.ts
import { entity, field, policy, buildManifest } from '@pylonsync/sdk';

const Note = entity(
  'Note',
  {
    title: field.string(),
    body: field.richtext(),
    authorId: field.string(),
    updatedAt: field.datetime(),
  },
  {
    indexes: [{ name: 'by_author', fields: ['authorId'], unique: false }],
  },
);

const notePolicy = policy({
  name: 'note_public',
  entity: 'Note',
  allowRead: 'true',
  allowInsert: 'auth.userId == data.authorId',
  allowUpdate: 'auth.userId == data.authorId',
  allowDelete: 'auth.userId == data.authorId',
});

export default buildManifest({
  name: 'notes',
  version: '0.1.0',
  entities: [Note],
  policies: [notePolicy],
  queries: [],
  actions: [],
  routes: [],
});

Une fonction serveur se place dans functions/ :

// apps/api/functions/createNote.ts
import { mutation, v } from '@pylonsync/functions';

export default mutation({
  args: { title: v.string(), body: v.string() },
  async handler(ctx, args) {
    const id = await ctx.db.insert('Note', {
      title: args.title,
      body: args.body,
      authorId: ctx.auth.userId,
      updatedAt: new Date().toISOString(),
    });
    return { id };
  },
});

Le client React peut ensuite s’abonner à une fonction réactive :

import { db } from '@pylonsync/react';

function Feed({ userId }) {
  const { data: notes, loading, error } = db.useReactiveQuery('getNotes', { userId });

  if (loading) return <Spinner />;
  if (error) return <ErrorBanner error={error} />;
  return notes.map((note) => <NoteCard key={note.id} note={note} />);
}

Quels sont les points forts et les limites de Pylon ?

• Serveur Rust unifié avec Bun pour les fonctions TypeScript et le SSR.
• SQLite ou PostgreSQL, sans moteur de persistance imposé.
• Politiques d’accès par ligne déclarées près du schéma.
• Requêtes réactives, synchronisation temps réel, authentification et stockage de fichiers intégrés.
• Licences MIT ou Apache 2.0 pour le dépôt principal.

Pylon offre davantage de contrôle sur l’infrastructure, mais son projet et son écosystème sont plus jeunes. Vous devez donc valider soigneusement l’exploitation, les intégrations et les limites des requêtes réactives sur votre charge réelle.

Convex ou Pylon : quelles différences ?

Critère	Convex	Pylon
Expérience principale	Backend réactif avec cloud managé	Framework full-stack auto-hébergeable
Persistance	Service Convex ; SQLite, PostgreSQL ou MySQL en open source	SQLite ou PostgreSQL
Temps réel	Requêtes réactives et clients synchronisés	Requêtes réactives, live queries et synchronisation
Déploiement	Cloud Convex ou auto-hébergement	Binaire ou dépendance de projet, Docker ou cloud
Licence du backend	FSL Apache 2.0, puis Apache 2.0 après le délai prévu	MIT ou Apache 2.0
Maturité	Écosystème et documentation plus établis	Projet plus récent, périmètre full-stack plus large

Convex est le choix le plus prudent si vous recherchez avant tout une expérience développeur intégrée et un service exploité pour vous. Pylon devient intéressant lorsque vous voulez maîtriser la base, le serveur et le déploiement avec des composants standards.

Le backend réactif crée-t-il un vendor lock-in ?

Oui, en partie. Le verrouillage ne vient pas seulement du stockage. Il vient surtout des fonctions serveur, des hooks clients, des règles d’accès et du modèle de requêtes propres à chaque plateforme.

Convex réduit le risque opérationnel grâce à l’export ZIP ou continu des données et à son backend auto-hébergeable. Pylon limite le verrouillage de la persistance en utilisant SQLite ou PostgreSQL et en publiant son serveur sous licences MIT ou Apache 2.0.

Avant de choisir, vérifiez donc trois sorties :

1. Pouvez-vous exporter les données et les fichiers dans un format exploitable ?
2. Pouvez-vous exécuter le backend sans le cloud de l’éditeur ?
3. Combien de logique faudrait-il réécrire pour revenir à une API standard ?

Quand choisir Convex ou Pylon ?

Choisissez Convex si :

• vous voulez livrer rapidement avec un cloud managé ;
• le typage et l’intégration React priment ;
• vous avez besoin de recherche vectorielle ou de fonctions planifiées ;
• la restriction FSL ne gêne pas votre modèle économique.

Choisissez Pylon si :

• vous voulez contrôler l’hébergement et la base de données ;
• SQLite ou PostgreSQL correspondent déjà à votre exploitation ;
• une licence MIT ou Apache 2.0 est un critère décisif ;
• vous acceptez d’évaluer un écosystème plus récent.

Pour une API publique surtout transactionnelle et peu interactive, gardez aussi l’option d’un backend classique. La réactivité apporte le plus de valeur lorsque plusieurs clients doivent afficher le même état presque immédiatement.

Conclusion

Convex et Pylon rendent le temps réel plus déclaratif : vous écrivez la lecture et le système se charge de maintenir les abonnés à jour. Cette abstraction élimine une part importante du code de synchronisation, mais elle déplace aussi davantage de responsabilités dans le framework.

Je recommande Convex par défaut pour lancer un produit réactif, grâce à son expérience intégrée et à son option managée. Je choisirais Pylon pour un projet où l’auto-hébergement, SQLite ou PostgreSQL et la liberté de licence sont non négociables. Dans les deux cas, testez d’abord une fonctionnalité représentative et documentez votre stratégie de sortie.

Sources

• Vue d’ensemble de Convex
• Auto-hébergement et licence de Convex
• Export des données Convex
• Introduction à Pylon
• Requêtes réactives de Pylon
• Dépôt officiel de Pylon