Alternative à Firebase pour les données d'app : persistance simplifiée pour prototypes

Si vous avez cherché Firebase alternative for app data, vous voulez le chemin le plus court et le plus fiable du code fonctionnel à une URL publique — sans déployer de serveurs, sans apprendre un tableau de bord cloud complexe, 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 vraiment le meilleur choix. Nous restons 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.
Pourquoi c'est important pour une alternative Firebase aux données d'app
La plupart des prototypes n'ont pas besoin de Postgres. Ils doivent sauvegarder un objet de paramètres, persister un meilleur score, stocker une liste de soumissions, ou se souvenir de ce qu'un utilisateur a fait la dernière fois. Un store JSON touche le bon équilibre : 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 vraie base.
Modes et contrôle d'accès
Le datastore fonctionne en l'un des deux modes. En public_read, tout le monde peut lire les enregistrements mais les écritures exigent votre clé store_. En private, lectures et écritures exigent la clé. Les requêtes PUT sont limitées en débit par IP. La clé est un secret partagé adapté aux données non sensibles — ne mettez jamais de vrais secrets dans le code côté client.
Exemple : sauvegarder 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 les lignes owner
Chaque visiteur doit avoir ses propres données privées ? Combinez le datastore avec l'auth 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 les démos protégées et les apps simples par utilisateur sans backend complet.
Quand ce n'est pas adapté
Soyez honnête avec votre modèle de données. Le datastore n'est pas l'outil pour les données relationnelles avec jointures, migrations de schéma ou transactions ; il n'offre pas d'abonnements temps réel, pas de fonctions ou triggers côté serveur, pas 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.
Pour qui c'est fait, et quand ne pas utiliser jsdeck
Bon choix : 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.
Pas adapté : apps qui exigent un serveur Node longue durée, du rendu côté serveur à la requête, des backends WebSocket, des secrets côté serveur privés, des tâches en arrière-plan ou une base relationnelle complète. Pour ceux-là, une plateforme comme les alternatives discutées dans notre hub de comparaisons vous conviendra mieux — et c'est un choix délibéré, pas un compromis.
Questions fréquentes
Une alternative Firebase pour les données d'app est-elle vraiment gratuite ?
Oui. jsdeck propose un hébergement statique gratuit avec HTTPS pour des projets comme celui-ci, sans carte bancaire pour commencer. Des fonctionnalités optionnelles comme le datastore et l'auth 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.
Comment garder les données de chaque utilisateur privées ?
Utilisez l'auth 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