PostgreSQL : Supabase annone la mise en libre accès de Postgres-wasm,

Un serveur PostgreSQL qui fonctionne dans un navigateur

Le 4 octobre 2022 à 09:59, par Bruno

39PARTAGES

Supabase a annoncé la mise en libre accès de postgres-wasm. Postgres-wasm est un serveur PostgreSQL qui fonctionne dans un navigateur. Il offre une suite complète de fonctionnalités, notamment la persistance de l'état dans le navigateur, la restauration à partir de pg_dump et la réplication logique à partir d'une base de données distante. « Aujourd'hui, nous mettons en libre accès postgres-wasm avec nos amis de Snaplet », a déclaré Mark Burggraf, ingénieur chez Supabase dans un post publié le 3 octobre.

Postgres est l'un des systèmes de gestion des bases de données open source les plus avancés. Il est riche en fonctionnalités, avec des types de données robustes, une indexation puissante et un large éventail de fonctions intégrées que peuvent être utilisé pour simplifier la pile de données et permettre aux développeurs de se concentrer sur la création de son application. Postgres est plus qu'une base de données relationnelle, il a évolué pour devenir votre plateforme de données de confiance. Il dispose de :

une base de données relationnelle ;
une base de données documentaire avec un support JSON complet ;
un support géospatial ;
partitionnement pour les données de séries chronologiques.

Supabase n’est pas premier à faire fonctionner Postgres dans un navigateur - ce titre revient à l'équipe de Crunchy Data qui a partagé sa version sur HN il y a un mois. Dans son désir de développer une version open source de la version propriétaire de Crunchy Data, Supabase s’est associé à Snaplet pour construire Postgres-wasm. Snaplet fournit aux développeurs des données précises pour la production et des bases de données de prévisualisation sur lesquelles ils peuvent coder, afin qu'ils puissent se concentrer sur l'expédition. Il est possible d’utiliser Snaplet pour cloner les environnements Supabase.

Environnements de clonage de Supabase

Clonez les données de production de Supabase, sans informations personnelles, vers un environnement de développement. La « parité d'environnement » est un terme introduit par la « méthodologie des applications à 12 facteurs » qui demandait aux développeurs de conserver des environnements aussi similaires que possible afin d'avoir la certitude que si cela « fonctionnait sur ma machine », cela fonctionnerait en production.

Si vos environnements de développement, de test et de production sont différents, vous perdez la capacité de prédire avec précision comment votre changement de code va se comporter en production. Cette confiance dans le code destiné à la production est essentielle pour le type de livraison continue et de déploiement rapide qui permet aux applications et à leurs équipes de développement de prospérer dans le cloud. Voici, ci-dessous, une vidéo dans laquelle Peter Pistorius, fondateur de Snaplet, montre le processus :

Snaplet fournit aux développeurs des données précises pour la production et des bases de données de prévisualisation sur lesquelles ils peuvent coder, afin qu'ils puissent se concentrer sur l’essentiel.

Il s'agit de PostgreSQL, exécuté dans une machine virtuelle à l'intérieur du navigateur. Psql, l'outil de ligne de commande PostgreSQL, peut être utilisé pour interagir avec la base de données.

Pour l'exécuter localement :

Code :

Sélectionner tout

1
2
3
4
5
6
7
8
9
10
11
# From Snaplet Repo 
git clone git@github.com:snaplet/postgres-wasm.git 
cd postgres-browser/packages/pg-browser 
npx serve 
 
# From Supabase Fork 
git clone git@github.com:supabase-community/postgres-wasm.git 
cd postgres-wasm 
git checkout web 
cd packages/supabrowser 
npx serve

postgres-wasm pèse actuellement environ 30 Mo. Donc, à ce stade, l'exécution de Postgres dans le navigateur n'est pas idéale pour les cas d'utilisation générale. Il y a cependant beaucoup de potentiel. Une machine virtuelle (MV) intégrable est créée à l'aide de Buildroot. La MV est un build Linux avec Postgres installé.

Le but de ce processus de construction est de produire un dossier contenant un système de fichiers Linux complet qui sera monté et servi par v86.

Construire et lancer le conteneur pour exécuter Buildroot

./build.sh
Modifiez la configuration et sauvegardez-la sur l'hôte.

# Linux system config
# Launch menuconfig
make menuconfig
# Save the changes back to the host
cp .config /config/.config

# Linux kernel config
# IMPORTANT: If it's the first time you run this command,
# exit the linux-menuconfig when it opens and copy the host file by running
# cp /pg-browser/board/pg-browser/linux.conf ./output/build/linux-5.17.15/.config
# then you can go back to "make linux-menuconfig" to edit this configuration
# Launch menuconfig
make linux-menuconfig
# Save the changes back to the host
cp output/build/linux-5.17.15/.config /config/board/pg-browser/linux.conf

Construire le dossier du système de fichiers :

makeEnsuite la MV doit être exécutée dans un navigateur. WebAssembly (parfois abrégé Wasm) définit un format de code binaire portable et un format de texte correspondant pour les programmes exécutables ainsi que des interfaces logicielles pour faciliter les interactions entre ces programmes et leur environnement hôte.

L'objectif principal de WebAssembly est de permettre la réalisation d'applications performantes sur des pages Web, « mais il ne fait pas de suppositions spécifiques au Web et ne fournit pas de fonctionnalités spécifiques au Web, il peut donc être utilisé dans d'autres environnements également ». C'est un standard ouvert qui vise à supporter n'importe quel langage sur n'importe quel système d'exploitation et, en pratique, tous les langages les plus populaires ont déjà au moins un certain niveau de support. Supabase utilise v86 pour exécuter sa MV à l'intérieur du navigateur.

Proxy réseau

Exécuter Postgres dans un navigateur est génial, mais s'y connecter avec PgAdmin est encore mieux. Malheureusement, les navigateurs bloquent l'accès au réseau TCP de la MV. Pour contourner cela, Supabase fait passer le trafic par des websockets. Ils utilisent un fork de Websockproxy qui permet à l'émulateur de communiquer avec Internet en convertissant les données envoyées sur un port websocket en paquets TCP. Le fork de Websockproxy ajoute la possibilité de tunneliser le serveur Postgres.

WASM

La première chose à souligner est que la mise en œuvre de Supabase n'est pas purement WASM. Ils ont essayé de compiler Postgres pour WASM directement à partir de la source, mais c'était plus compliqué que prévu. Le post HN de Crunchy a fourni quelques indices sur l'approche qu'ils ont prise, qui était de virtualiser une machine dans le navigateur. Supabase a également suivi cette stratégie et a opté pour v86 qui émule un CPU et un matériel compatible x86 dans le navigateur.

Erreurs de segfault de PostgreSQL 14

Supabase a rapidement fait fonctionner PostgreSQL 13.3 en utilisant une version obsolète de Buildroot. Mais la version PG14+ ne voulait pas démarrer, donnant un segfault pendant l'initialisation. L'équipe à essayé :

de copier manuellement les fichiers de construction pour PG14 dans la ou les anciennes versions de Buildroot ;
construire avec les (nombreuses) copies plus récentes de Buildroot ;
ajustement des paramètres du noyau et de l'environnement, comme la quantité de mémoire allouée à l'émulateur, etc.

Finalement, Fabian, le créateur de v86, a suggéré que l'équipe Supabase désactive la compilation JIT pour v86 et cela a résolu le problème. Il a déterminé qu'il s'agissait d'un bogue dans v86 et a publié une mise à jour qui le corrige. Le passage de Postgres de posix à la gestion de la mémoire sysv a également résolu le problème pour la version actuelle de v86.

Optimisation du temps de démarrage et de la taille des images

Avec PG14 fonctionnant dans l'émulateur, nous nous sommes concentrés sur les performances. La taille de l'image de l'émulateur était trop importante pour un outil basé sur un navigateur. Même avec nos meilleurs efforts, un instantané compressé dépassait les 30 mb - une charge utile assez importante à télécharger avant de pouvoir voir une quelconque interaction. Supabase a résolu ce problème en ne démarrant qu'une image Linux minimale, puis en chargeant dynamiquement le reste de la VM via HTTPS après l'initialisation.

Pour ce faire, Snaplet monte un système de fichiers 9P compressé dans la MV. 9P fournit un script Python qui prend un dossier de système de fichiers, renomme chaque fichier avec un nom à 8 caractères et produit un fichier filesystem.json représentant une structure imbriquée avec des fichiers, des noms de fichiers originaux, des tailles, etc. Nous copions ensuite cette sortie compressée sur la VM. Snaplet a modifié la ligne de commande du noyau et les paramètres de démarrage de v86 pour démarrer directement à partir du système de fichiers 9P, et a même placé le fichier noyau dans le système de fichiers p9. Tous les fichiers non essentiels sont chargés de manière asynchrone par HTTPS dans le navigateur selon les besoins.

Source : Supabase

Et vous ?