Un serveur web qui permet d'accèder à une base PostgreSQL directement via une API REST!

Exemples:

• SELECT avec WHERE 👉 GET /people?age=gte.18&student=is.true
• un JOIN sur la table directors 👉 GET /films?select=title,director:directors(id,last_name)

J'ai toujours été fasciné par le fonctionnement des liseuses électroniques.

Dans cette vidéo, l'auteur démonte un Kindle et le regarde sous toutes ses coutures avec microscope de surface et même microscope électronique !

L'écran est composé des centaines de milliers d'électrodes qui peuvent se charger négativement et positivement.

Au dessus de chacune de ces électrodes, il y a des capsules contenant un pigment noir chargé positivement et blanc charge négativement qui montent (et deviennent donc visibles) ou descendent en fonction de la charge des électrodes.

C'est pour ça que l'autonomie est aussi bonne: le courant est nécessaire seulement pour modifier l'affichage

Un framework pour créer des extensions PostgreSQL avec Rust.

Je ne savais pas mais à priori Rust est un langage de choix pour les extensions PostgreSQL maintenant.

C'est un très bon usecase car dans une base de données on a justement besoin de performances et de memory safety

Tous les conseils pour bien choisir sa clé primaire.

Dans la plupart des cas, un entier auto-incrémenté (serial) est suffisant, cependant il a quelques désavantages:

• prédictible: il est facile d'énumérer les ID et de deviner des choses comme le nombre d'utilisateurs sur un site (yoursite.com/users/41 renvoi le profil mais yoursite.com/users/42 renvoi une 404)
• ce n'est pas un standard SQL

Une autre possibilité est d'utiliser un UUID v4 car ceux ci sont totalement aléatoires. Par contre on a d'autres problèmes:

• pas possible de les trier
• beaucoup plus gros que notre entier auto-incrémenté
• leur indexage par la base de donnée est très difficile

C'est pour ça que d'autre types d'UUID sont apparus (voir UUID v7 et ULID), cette dernière génération inclue un timestamp afin de pouvoir les trier par exemple.

L'article termine sur un benchmark sur la vitesse de génération dans PostgreSQL mais aussi de la taille de la table et de son index.

Niveau vitesse, tous sont plus ou moins équivalents à part pour pushid et nanoid qui sont significativement plus lents.

Au niveau de la taille, sans surprise les dernières version d'UUID font augmenter l'espace utilisé.