Une lib AWS qui wrap toute la complexité pour déployer une application fullstack sur AWS.

Ça permet d'utiliser les services AWS comme EC2, S3, RDS (Postgres), de l'authentification et pleins d'autre chose simplement en instanciant des classes dans du code.

Un article critique sur Bun.

Pas mal de bashing un peu gratuit et de demi vérité:

• performances: tout ce qui est lancé en local avec Bun est instant vs plusieurs secondes avec une stack Typescript standard
• pas de version manager: Bun vient d'être release et il y a litéralement 3 versions donc pas vraiment besoin, be patient ^^
• moins de backward compat que Node: en même temps on attends pas la même chose de Bun, et au moins les features sortent :)

Bref en tout cas je ne pense pas que Bun puisse un jour remplacer Node côté serveur car il y fallut plusieurs années pour que l'industrie fasse confiance à Node et que Node se montre suffisamment mature.

Par contre en local il n'y a rien à dire, bosser dans l'écosystème actuel c'est juste HORRIBLE entre les bundler, les builders, les compilers et les fichiers de config de la mort j'étais à la limite de craquer et heureusement Bun vient régler tout ça.

Pas de tsconfig.json, pas de webpack.config.js, pas de ts-node, pas de jest.
It just works ©

En plus bonus: c'est instantané de lancer un script ou de run +100 tests unitaires

Une technique pour wrapper les handler API dégueulasses forcés par l'utilisation de Express en quelque chose d'un peu plus moderne.

Next.js encore sur Express en 2023 :(

Présentation de l'architecture Backend for Frontends telle qu'elle a été conceptualisé au départ chez Souncloud

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 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  ?

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.

Une très bonne explication des nombreux avantages de la programmation avec le langage Rust créé par Mozilla.

Rust offre de très bonnes performances, proches du C et du C++ tout en proposant un modèle de gestion de la mémoire innovant.

Jusqu'ici, la gestion de la mémoire était soit un facteur de dégradation des performances du à l'introduction d'un garbage collector (Java, Go, C#), soit un facteur de risque de sécurité important (buffer overflow, use-after-free, segmentation fault, etc.)

Rust introduit un mécanisme ou une référence peut être soit constante et partagée, soit mutable mais unique (Borrow Checker).

La gestion des erreurs est aussi plutôt pas mal en prenant le meilleur du système d'exceptions (implicite) et du système de retour d'erreur (explicite)

// the "?" operator mean that potential errors will be propagated
let result = foo()?.bar()?;

Un autre avantage est le potentiel de portabilité dans le navigateur avec WASM. Il est possible d'utiliser Rust comme langage fullstack à l'instar de Javascript.

Il y a aussi bien sur des choses plus compliqués avec Rust:

• la syntax inhabituelle
• temps de compilation assez long
• ecosystème naissant

L'histoire d'une grosse migration backend chez LinkedIn et un retour d'expérience très intéressant.

Les sujets de migration sont toujours très sensibles car ils ont un impact fort et sont sujets à de nombreux risques.

L'équipe de LinkedIn donne quelques conseils:

• s'assurer que tout le monde comprenne l'intérêt de la migration et du nouveau système
• écrire des instructions étape par étape clair et précises
• faire des outils automatiques dès que c'est possible
• faciliter un accès au support pour répondre aux questions
• monitorer les progrès

Un framework pour créer des API REST en codant les contrôleurs et modèles en TypeScript avec des annotations.

Ça génère automatiquement la spec OpenApi et les JsonSchema en plus.

(Merci Bombi pour le partage)

Un système de queing entièrement basé sur Redis.

Ils proposent toutes les fonctionnalités dont on a besoin:

• multi-queue producers et consumers
• garantie du delivery unique
• expiration des messages
• rate limiting

C'est toujours bien de voir émerger d'autres runtime car cela amène de nouvelles idées et concepts.

Par contre il ne faut pas se voiler la face, il y a très peu de chances que Deno ou Bun puissent remplacer Node.js.

L'industrie a mis des années avant de faire confiance à Node.js et aujourd'hui je vois difficilement les entreprises se tourner vers un nouveau runtime simplement pour des histoires de design ou quelques % de perfs en plus sachant que le coût d'adoption à l'échelle industriel est très élevé.

Une autre tentative de framework fullstack mais cette fois en utilisant un langage de haut niveau pour décrire une application.

Le "compilateur" Wasp (plutôt un générateur) va ensuite générer le code backend (Node.js), frontend (React) et le modèle de données (Prisma ORM).

C'est intéressant comme démarche mais à priori je vois deux limitations importantes:

• introduction d'un nouveau langage dans la stack (qui plus est un langage peu mature)
• manque de personnalisation du code généré (pour aller au delà du CRUD quoi)

Ça ressemble à ça le WASP:

// file: main.wasp

app TodoApp {
  title: "Todo App"
}

route RootRoute { path: "/", to: MainPage }
page MainPage {
  component: import Main from "@ext/pages/Main.js" // Importing React component.
}

query getTasks {
  fn: import { getTasks } from "@ext/queries.js", // Importing NodeJS code.
  entities: [Task]
}

entity Task {=psl
    id          Int     @id @default(autoincrement())
    description String
    isDone      Boolean @default(false)
psl=}