PocketBase sans auto-hébergement ? Un store JSON hébergé plus auth

Si vous avez recherché PocketBase alternative without self-hosting, vous voulez le chemin le plus court et le plus fiable entre un code qui fonctionne et une URL publique — sans monter de serveurs, sans apprendre un tableau de bord cloud tentaculaire, et sans saisir une carte bancaire avant d'avoir le moindre utilisateur. Ce guide explique exactement comment y parvenir avec jsdeck, quels sont les compromis, et quand un autre outil est réellement le meilleur choix. Nous resterons concrets : étapes réelles, commandes réelles et limites honnêtes.

Ce qu'est réellement le datastore jsdeck

C'est un store clé-valeur JSON par app. Chaque enregistrement a une key chaîne, une value JSON arbitraire, trois colonnes d'index chaîne optionnelles (idx1–idx3) pour le filtrage, et un horodatage updatedAt. Vous le lisez et l'écrivez via une petite API REST directement depuis votre frontend statique, ou via le client npm @jsdeck/toolkit. Aucun serveur à faire tourner, patcher ou scaler de votre côté.

Pourquoi c'est pertinent pour l'alternative PocketBase sans auto-hébergement

La plupart des prototypes n'ont pas besoin de Postgres. Ils ont besoin d'enregistrer un objet de paramètres, de persister un high score, de stocker une liste de soumissions, ou de se souvenir de ce qu'un utilisateur a fait la dernière fois. Un store JSON touche ce sweet spot : vous gardez vos données exactement comme l'état de votre app, sans la cérémonie de schéma, migration ou pool de connexions d'une base complète.

Modes et contrôle d'accès

Le datastore fonctionne dans l'un de deux modes. En public_read, tout le monde peut lire les enregistrements mais les écritures requièrent votre clé store_. En private, lectures et écritures requièrent la clé. Les requêtes PUT sont limitées en débit par IP. La clé est un secret partagé adapté aux données d'app non sensibles — ne mettez jamais de vrais secrets dans le code côté client.

Exemple : enregistrer et charger du JSON

// Save
await fetch('https://jsdeck.com/api/v1/public/data/YOUR-SLUG/records/settings', {
  method: 'PUT',
  headers: {
    'Authorization': 'Bearer store_YOUR_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ value: { theme: 'dark', lang: 'en' } }),
});

// Load
const res = await fetch('https://jsdeck.com/api/v1/public/data/YOUR-SLUG/records/settings');
const { value } = await res.json();

Données par utilisateur avec lignes owner

Besoin que chaque visiteur ait ses propres données privées ? Combinez le datastore avec l'authentification visiteur. Après connexion d'un visiteur, vous recevez un token de session ; écrivez un enregistrement avec visibility: "owner" et cette ligne devient lisible et modifiable uniquement par cet utilisateur. La clé store_ seule ne peut pas la lire. C'est ce qui rend possibles démos protégées et apps simples par utilisateur sans backend complet.

Quand ça ne convient pas

Soyez honnête avec vous-même sur le modèle de données. Le datastore n'est pas le bon outil pour des données relationnelles avec jointures, migrations de schéma ou transactions ; il n'offre pas d'abonnements temps réel, de fonctions ou triggers côté serveur, de recherche full-text, ni de stockage fichier/blob. Son modèle de requête est « clé plus jusqu'à trois index chaîne (combinés en AND) », pas du SQL arbitraire. Si vous avez besoin de tout cela, tournez-vous vers Postgres/Supabase ou un backend complet.

À qui s'adresse jsdeck, et quand ne pas l'utiliser

Bon usage : frontends statiques, single-page apps, démos, portfolios, MVPs, exports générés par IA, et apps qui ont besoin d'un peu de persistance JSON ou d'une connexion visiteur légère.

Mauvais usage : apps qui exigent un serveur Node longue durée, du rendu côté serveur à la demande, des backends WebSocket, des secrets côté serveur privés, des tâches en arrière-plan ou une base de données relationnelle complète. Pour ceux-là, une plateforme comme les alternatives discutées dans notre hub comparatifs vous servira mieux — et c'est une force de choisir délibérément, pas un compromis.

Questions fréquentes

L'alternative PocketBase sans auto-hébergement est-elle vraiment gratuite ?

Oui. jsdeck propose un hébergement statique gratuit avec HTTPS pour ce type de projets, sans carte bancaire requise pour commencer. Des fonctionnalités optionnelles comme le datastore et l'authentification visiteur sont disponibles quand vous en avez besoin.

Ai-je besoin d'un serveur pour utiliser le datastore ?

Non. Le datastore est une API REST hébergée que vous appelez directement depuis votre frontend statique. Rien à faire tourner, scaler ou patcher de votre côté.

Comment garder les données de chaque utilisateur privées ?

Utilisez l'authentification visiteur et écrivez des enregistrements avec visibility: "owner". Ces lignes ne sont accessibles qu'avec le token du propriétaire, pas la clé datastore partagée.

Prochaines étapes

• Explorer d'autres guides dans le hub datastore
• Suivre le guide de démarrage pour déployer votre première app
• Lire la documentation développeur pour le datastore, les comptes sécurisés (auth API) et les détails de déploiement CLI