Un framework Python pour intégrer des LLMs dans son code.
Je trouve la DX bien pensée par rapport à Langchain (pas difficile de faire mieux niveau DX)
On y retrouve simplement les fonctionnalités essentielles pour faire du LLM Engineering:
- choix du modèle, des paramètres
- intégration facile de l'historique de messages
- utilisation de fonctions par le modèle (Function Calling )
- chaines de prompt et sous prompt (vraiment bien foutu je trouve!)
- extraction de données structurées
Il ne manque que la validation et la possibilité de spécifier un format de sortie structuré pour chaque prompt. C'est du super boulot.
(Dommage que ce soit en Python)
Un framework pour construire facilement une application type chat avec des LLMs.
Pleins de fonctionnalités:
- suivi threads
- ajout de fichiers
- multi-modalité (images, son)
- frontend custom
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 :(
La sortie de Next.js 4 c'est surtout l'arrivée des Server Actions.
Ils ont presque terminé leur chantier de support de Turbopack plutôt que Webpack donc on peut s'attendre à une prochaine release avec des performances accrues! (Turbopack est en Rust et beaucoup plus performant que Webpack)
Un framework C++ pour construire des application server performantes.
Au menu:
- sharding
- network stack
- futur et promises (JS like <3)
- message passing pour le multithread (afin d'éviter les couteux lock)
ScyllaDB est écrit avec
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 article de fond sur l'évolution du développement frontend.
L'article commence par un historique du frontend:
- Pages dynamique CGI : PHP
- AJAX : JQuery, Flash
- Split frontend/backend : Backbone
- Two way binding : Angular
- JAMStack: Gatbsy, Next
- Components: React, Vue
Le frontend s'est tellement complexifié qu'on atteint des limites en terme de coût de manipulation du DOM (résolu par le Virtual DOM) mais également en terme de traffic réseau et du rendering des éléments d'une mage qui peuvent se bloquer entre eux (charger du CSS par exemple)
L'auteur revient sur les différentes innovations mises en place chez Facebook avec React:
- Optimizing runtime costs: Virtual DOM, CSS avec Stylex
- Optimizing the network: Relay, GraphQL
- Optimizing Javascript bundles: Tree shaking (Facebook utilisent carrément une IA !)
Les différents framework du marché sont passé en revue: React, Svelte, Vue, Solid, Astro, Marko, Fresh, Next, Remix et Qwik
Pour moi le plus important est cette phrase de l'auteur
It’s a good reminder that if you’re on the bleeding edge, you are usually the one bleeding. Defaulting to “boring” technologies, ones you are familiar with, and being a late adopter is often a great choice.
La morale c'est qu'il faut choisir son framework en fonction de ses besoins actuels et faire très attention aux choix techniques pour des projets long termes.
Un nouveau (LOL encore) framework Javascript frontend.
Ils se focalisent sur la vitesse lors du premier affichage de l'application en supprimant la phase d'hydratation.
Lorsque l'on télécharge une page web en React par exemple, le navigateur doit interpréter le HTML et le JS, puis:
- re-créer tous les listeners sur les noeuds du DOM
- re-créer l'arbre de composant représentant l'application
- restorer l'état (state) de l'application
Qwik permet de sauter ces étapes avec plusieurs astuces, par exemple pour les listeners, ils sont directement dans le HTML:
<button on:click="./chunk.js#handler_symbol">click me</button>
Sinon la syntax est très similaire à celle de React avec du JSX.
Un framework qui permet de créer des applications graphiques en Python pour faire de la dataviz.
Un article présentant un framework pour micro-frontend avec tout le tooling pour se simplifier la vie.
Attention car même avec Piral, gérer un ensemble de micro-frontend est beaucoup plus compliqué.
Une telle décision d'architecture doit se reposer uniquement sur un besoin d'organisation d'une grande équipe en plus petites équipes focalisée sur un domaine de l'application.
Plus d'info sur les micro-frontend https://links.aschen.tech/shaare/AuKMeA
Une super présentation sur le fonctionnement et l'utilisation de Rust + WebAssembly pour faire une application frontend avec le framework Yew.
L'auteur utilise le framework frontend Yew en Rust.
Comme il le dit à la fin, pour l'instant c'est encore très expérimental et les performances ne sont pas au rendez-vous.
D'ailleurs c'est assez peu probable de pouvoir battre les performances du JS natif en terme de manipulation de DOM.
Aussi, ce genre d'application hybride (2 langages) aura quasiment toujours des performances inférieurs à cause de l'overhead du boxing / unboxing
Le framework pour application Tauri prend de plus en plus de maturité pour remplacer notamment Electron.
Concrètement le backend de l'application est à écrire en Rust et le frontend peut être en Javascript (React, Vue, Angular, etc).
Les deux vont communiquer via une API RPC:
// (Rust) Tauri command
#[tauri::command]
fn return_string(word: String) -> String{
return word
}
// (Javascript) Command invocation
const result = await invoke("return_string", {
word: "This is the argument"
});
J'espère sincèrement que ça prendra car les application Electron sont vraiment trop lourdes avec des appli comme Slack qui sont régulièrement à ~15-20% du CPU même en idle (!!).
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=}
Earthly est un framework pour définir ses jobs de CI.
On écrit le job dans une syntax qui ressemble à un Dockerfile et ensuite on peut l'exécuter dans une CI (Github, Gitlab, Jenkins, etc) mais aussi sur sa machine en dev !
Ça permet de tester le fonctionnement des étapes de CI en local donc énormément de temps gagné lors de la mise en place.
# Earthfile
VERSION 0.6
FROM golang:1.15-alpine3.13
RUN apk --update --no-cache add git
WORKDIR /go-example
all:
BUILD +lint
BUILD +docker
build:
COPY main.go .
RUN go build -o build/go-example main.go
SAVE ARTIFACT build/go-example AS LOCAL build/go-example
lint:
RUN go get golang.org/x/lint/golint
COPY main.go .
RUN golint -set_exit_status ./...
Puis dans la CI où en local: earthly +all
Un framework CRUD "fullstack": le code pour manipuler le CRUD des modèles est le même en front et en back.
Sinon c'est basé sur Express avec des classiques règles de validations.
En gros ça expose une API pour du CRUD à la manière d'un backend clé en main qui peut être manipulé dans du frontend ou un autre backend
Un framework pour développer des extensions navigateur !
Un framework backend pour Dart.
Le principe du 1 fichier = 1 route est franchement limitant et un peu désuet je trouve
Un framework fullstack avec une structure et une syntax inspirée de Ruby On Rails (particulièrement pour l'ORM).
C'est un des créateurs de Github derrière ce projet, pas étonnant que ça ressemble autant à Rails!
Ils exposent une API GraphQL, une auth générique, un ORM basé sur Prisma et utilisent React pour le frontend
Un backend temps réel exposant une API GraphQL pour une utilisation avec les React Hooks (mais pas que)
Un framework fullstack qui gère la partie backend et la partie frontend (en React).
Des idées intéressantes par rapport aux traditionnels framework MVP comme une construction autour des routes uniquement et une abstraction du serveur HTTP avec un support de Node, Express, Deno et autres en utilisant le standard de l'API fetch à la place