Un article qui parle des uuidv7 qui comportent une composante temporelle pour être triable par défaut tout étant utilisables dans des systèmes distribués car uniques.
Les performances sont bien supérieures et ça vient du fait qu'ils possèdent une partie aléatoire moins importante (en plus du fait qu'ils soient triable)
Un boilerplate pour lancer un produit avec tout ce qu'il faut:
- app front (Tailwind) et back avec Next.js et MongoDB
- Stripe déjà configuré pour le paiement
- Mailgun pour les mail
- NextAuth avec Google login ou magic link
- SEO etc
L'utilisation de Protobuf se démocratise de plus en plus pour remplacer le JSON en tant que format d'échange de données.
Cela devrait être le choix par défaut pour toute communication inter-serveur.
Attention néanmoins dans les environnements JS la différence de performances n'est pas assurée donc pensez à benchmarker ;-)
Un snake en 70 octets d'assembleur, jolie performance!
Un autre article qui résume bien les possibilités de Supabase.
Aussi, des retours de Ali de Tech.rocks:
So far les craintes soulevées :
Le système d’Auth semble extensible mais par exemple ne semble pas gérer de token CSRF out of the box (lorsque le client et le server sont sur le même host, les cookies transmettent le jwt à la place d’un authentification bearer). On est en train d’explorer le flux sur un host différent.
Le back-end est composé grosso-modo d’une base postgres dont les tables sont exposées via une API REST ou GraphQL et d’edge functions
-> cela nous pose la question de comment mettre en place une couche de service métier exposée via API correctement testée
-> pas encore 100% convaincu par rapport à une stack classique Serverless ou Nest
-> on va expérimenter les edge functions mais à trouver/confirmer encore la bonne architecture pour créer notre couche métier (si vous avez des pointeurs)
je suis comme toi, je ne souhaite pas mettre trop de logique métier dans le SQL car beaucoup plus difficilement testable automatiquement et unitairement ? d’autant plus quand l’équipe grandit ? (si vous avez des pistes également nous sommes preneur)
le côté admin wysiwyg est séduisant mais rarement utilisé dans un vrai env de dev. On est en train d’évaluer la développeur expérience avec un env de dev local tout ce qui est database migrations, type generation, testing pour avoir un workflow dev/preprod/prod correct.
Les choix architecturaux de back-end sur lesquels on hésite sont : soit backend-as-a-service comme supabase, construire l’ensemble du back 100% en serverless derrière une API gateway, utiliser une architecture plus classique comme Nest.js
Une question en suspens, est quelle serait la meilleure architecture de départ pour implémenter du realtime (basé sur des sockets) pour avoir du push vers le client lors de mise à jour dans la base ?
Plusieurs article sur la manière de créer une timeline pour une application à fort trafic en utilisant Redis.
https://redis.io/docs/manual/patterns/twitter-clone/
https://livebook.manning.com/book/redis-in-action/chapter-8/
Retour d'expérience sur Supabase et quelques une de ses limitations
- pas de raw sql query "out of the box"
- définition de la DB en SQL vs avec un schéma à la Prisma
- couplage fort DB / frontend
- Système de droits ABAC (attributs based)
Bun est sorti en version 1.0 et ça s'annonce très prometteur.
Finit les prises de tête de l'écosystème Node.js, ça règle tous les problèmes de toolchain de run Typescript, de build en tout genre, de test runner, de module mjs/esm, de require vs import, de package manager en fournissant un seul outil qui just works
Même pas besoin de "risquer" une utilisation en prod, juste le fait de l'utiliser comme toolchain backend fait gagner en productivité.
Une solution pour utiliser Nest.js devant Supabase tout en conservant le système d'authentification de Supabase.
Supabase propose de faire des Edge Function pour la logique métier spécifique en Dart.
C'est cool car ça contribue à populariser l'utilisation de Dart pour le backend.
Un schéma builder pour GraphQL
Un assistant AI pour écrire du code, générer des tests, faire du refactoring etc
Un article qui détaille les autres types d'approche que la classique pyramide unit - integration - e2e pour le testing
Des chercheurs ont réussi à avoir de meilleurs résultats que BERT et son réseau de neurones sur des tâches de classification de texte avec un classifieur très simple utilisant l'algorithme de compression gzip!
Petit rappel à l'ordre sur la complexité croissante et souvent inutile en informatique.
6 techniques avancées d'utilisation de Typescript:
- types mappés: itération sur les clés ou types conditionnels
- décorateurs
- namespaces
- mixins (ça me rappelle Ruby :D)
- type guards
- utility types
Excellent article technique sur la manière dont Prisma à amélioré les performances au démarrage de son ORM.
La majorité du chemin a été achevé en simplifiant le protocol de communication interne en passant à du simple JSON.
Sinon on retrouve des choses assez classiques en terme d'optimisation, du lazy loading, pas de couche de chiffrement superflue et d'autres choses.
L'article décrit aussi le cycle de démarrage d'une lambda AWS.
De bons conseils pour rentrer dans un projet ayant déjà une grosse codebase.
J'aime notamment l'idée de prendre de petits commits récents et d'essayer de les reimplementer soit même
Typescript est carrément Turing complete!
L'auteur a implémenté un sous langage type brainfuck et Typescript est capable de l'interpréter.
const test1 = interpreter('*>*>*', '000000'); // '111000'
Le comité ISO a terminé de travailler sur la norme SQL 2023.
Au programme quelques améliorations du langage (qui étaient déjà supportées dans de nombreuses DB comme Postgres par exemple) mais surtout l'introduction du support du JSON et des graphes.
Par exemple les chemins seront simplement accessible avec des "."
// {"foo": {"bar": [100, 200, 300]}, ...}
SELECT t.j.foo.bar[2], ... FROM table ...