Un sérieux concurrent à Vercel

Dans la famille des Backend as a Service, je vous présente un nouveau venu: AppWrite

Vous connaissez probablement Vercel en tant que développeur Next.js, ou encore, vous connaissez Supabase, qui est assez proche de ce que fait AppWrite.

Et comme Supabase, AppWrite permet de déployer un serveur auto-hébergé.

Donc vous pourrez:

• mettre en ligne votre backend à moindre coût (le prix d'un VPS)
• héberger en mode full-saas pour 15€ contre 20€ pour Vercel (on va dire kif-kif)

Présentation d'AppWrite

Quelles sont les fonctionnalités proposées par AppWrite ?

On pourra lister:

• gestion de l'authentification (avec ajout possible de providers)
• gestion des bases de données (création de models sur mesure directement depuis le backend, via l'interface graphique)
• gestion des événements (subscriptions, etc...) pour la partie temps réel
• gestion des remote functions (comme les lambdas)
• gestion des fichiers (comme des buckets S3)

Et c'est déjà pas mal, mais contrairement à un service qui vous expose un accès à la base comme Supabase, AppWrite vous propose une approche API de tous ces services.

C'est à dire que vous n'allez pas écrire des requêtes mais consommer des API qui vont exposer la donnée. On pourra donc dire que le service se veut comme une sorte de Firebase auto hébergé, où finalement AppWrite tient un peu plus ses promesses comparé à Supabase qui ne fait pas d'abstraction sur la partie query.

Est-ce un game changer ?

C'est possible !

Supabase avait déjà fait beaucoup de bruit à sa sortie sur des fonctionnalités telles que les Vector tables qui permettent de mettre en place des produits orienté IA.

Aujourd'hui, la promesse est un peu différente, AppWrite vous propose une alternative à AWS à héberger vous même sur vos machines.

Lorsque l'on prête un peu d'attention aux services déployés sur le docker-compose fourni par AppWrite, on peut voir les services suivants:

• un proxy Traefik
• 23 process dédiés à AppWrite (worker, http, scheduler, etc...)
• une base de données (mariadb)
• un redis

Donc, on comprend vite que pour déployer ce projet il va falloir un minimum de ressource.

La configuration recommandée est la suivante:

• 2 cores
• 4GB ram
• 2GB swap

Mais je recommande plutôt:

• 4 cores
• 8GB ram
• 2GB swap (éviter d'augmenter le swap, et privilégier la ram pour éviter la latence de dump)

Au moins avec cette seconde configuration, vous bénéficierez d'une expérience fluide.

Mais la liste des services déployés montre que le projet est conséquent.

Etant donné la vague de migration du full cloud vers baremetal qui opère ces dernières années à cause des coûts. Ce projet va dans le sens de la tendance permettant une alternative solide aux SaaS cloud aujourd'hui sur le marché.

Conclusion

AppWrite est un renouveau en termes de Backend-as-a-Service.

Ce qu'il propose est réellement intéressant et son avantage n'est pas de proposer quelque chose de nouveau car ce sont des services que nous connaissons, que nous avons probablement l'habitude d'utiliser.

Mais son approche de projet à héberger est une réelle alternative aux solutions existantes, souvent à l'origine de frustrations (le prix non maîtrisé, une opacité fonctionnelle, etc.)

J'ai hâte de mettre un peu plus les mains dedans et explorer chacun de ses services.

Je vous proposerai prochainement un projet boilerplate à partir d'une base Vite React TS et AppWrite en backend.