Supabase

Un backend complet sur PostgreSQL en un déploiement - ce que vous obtenez, quelle base choisir, et où sont vos clés.

Supabase est un backend que vous n'avez pas à écrire : connexion des utilisateurs, API sur vos tables, temps réel, stockage de fichiers et fonctions côté serveur, le tout sur une base PostgreSQL. Sur ISOGrid, c'est une solution comme les autres - choisissez une taille, une base, déployez - et le projet est prêt en quelques minutes.

Ce que contient un projet

Tout ce que contient la distribution auto-hébergée de Supabase :

  • Studio, le tableau de bord : tables, éditeur SQL, utilisateurs, stockage, politiques.
  • Auth : inscription et connexion par e-mail et mot de passe, avec des jetons reconnus par votre API.
  • API REST et GraphQL, générées à partir de vos tables et protégées par la sécurité au niveau des lignes.
  • Realtime : Broadcast, Presence et changements de la base par websockets.
  • Storage : buckets et fichiers, avec redimensionnement d'images.
  • Edge Functions : votre propre TypeScript, exécuté côté serveur.

Une seule adresse sert l'ensemble. Studio demande l'identifiant affiché dans l'onglet Aperçu du projet.

Choisir la base de données

Le projet vit dans une base PostgreSQL, dont vous choisissez le type au déploiement :

Une mini-base - une base sur un serveur partagé avec d'autres clients. La façon la moins chère de commencer, et tout fonctionne sauf une chose : Realtime diffuse Broadcast et Presence, mais pas les changements de la base. Les écouter exige une permission qui, sur un serveur partagé, atteindrait les données d'autres clients ; elle n'y est donc pas accordée.

Un serveur PostgreSQL à vous - simple, avec pooling ou haute disponibilité. Supabase au complet, changements de la base compris. C'est le choix pour la production.

Un serveur que vous avez déjà - le projet garde ses schémas (auth, storage, realtime) dans la base principale de ce serveur, à côté de vos tables. Un projet par serveur.

Une base achetée avec un projet en fait partie. Elle n'apparaît pas parmi vos bases, elle se gère depuis l'onglet Base de données du projet, et elle est supprimée avec lui.

Vos clés

L'onglet Clés d'API contient ce dont un client a besoin :

  • l'URL du projet ;
  • la clé anon, que l'on peut livrer dans un navigateur ou une application mobile - la sécurité au niveau des lignes décide de ce qu'elle voit ;
  • la clé service_role, qui contourne cette sécurité. Gardez-la sur vos serveurs ;
  • le secret JWT et la chaîne de connexion à la base, pour les migrations et les clients SQL.
import { createClient } from '@supabase/supabase-js'

const supabase = createClient('<URL du projet>', '<clé anon>')

Les clés ne changent pas quand le projet est redéployé ou redimensionné.

Réglages

Dans Réglages : où un lien de confirmation envoie les utilisateurs, si l'inscription est ouverte, la durée d'une session, et le serveur de messagerie. Tant qu'aucun serveur de messagerie n'est défini, la confirmation par e-mail est ignorée - personne ne pourrait recevoir le lien. Définissez-en un et réactivez la confirmation avant d'ouvrir l'inscription au public.

L'enregistrement redémarre les services du projet. Ses données et ses fichiers ne sont pas touchés.

Edge Functions

L'onglet Fichiers ouvre le répertoire des fonctions. Chaque dossier est une fonction, servie à /functions/v1/<dossier> ; son code est le fichier index.ts qu'il contient. Une fonction hello sert de point de départ. Une fonction ne répond qu'aux requêtes portant une des clés du projet ou le jeton d'un utilisateur connecté.

Extensions

pgvector, PostGIS et les autres extensions de la liste de la plateforme s'activent depuis l'onglet Base de données. Voir Bases de données pour la liste.

Ce qui n'est pas inclus

L'analyse de journaux de Supabase n'est pas incluse ; la sortie de chaque service se lit dans l'onglet Journaux du projet. Les webhooks de base de données, qui appellent l'extérieur depuis la base, ne sont pas disponibles.