Une lib d'authorisation avec gestion des permissions RBAC
En plus du RBAC, il y a aussi une gestion ABAC (via les attributs avec un pseudo langage de matching).
La cerise sur le gateau c'est la gestion du multi-tenant (domains)
La persistence peut se faire dans tout type de base de données et ils possèdent des lib dans quasiment tous les langages.
Comment utiliser la commande npm link pour faire utiliser une librairie que l'on a en local plutôt que de la télécharger depuis NPM.
C'est utile pour travailler sur une lib externe qui est utilisé dans son application.
cd ~/projects/react
npm link # Step 1.
cd ~/projects/kuzzle-saas
npm link react(Merci Sébastien !)
Un article d'investigation puis de correction de problèmes de performances sur un grosse application React utilisant les Hooks.
Rome est un outil pour Javascript/Typescript qui sert de linter, formatter, bundler et test runner.
En gros ça remplace Eslint, Prettier, Webpack, Babel et Jest.
C'est écrit en Rust et beaucoup plus performant que les outils JS.
L'autre avantage est de n'avoir qu'un outil binaire plutôt que des centaines de dépendances et des centaines de méga-octets dans le dossier node_modules.
(Via Ludo)
Une base de données pee-to-peer, c-a-d qui permet de communiquer avec d'autres clients pour se synchroniser sur l'état commun partagé.
ça m'a l'air plutôt compliqué à gérer, surtout avec des clients malicieux mais par contre le côté offline first est toujours bon à prendre :-)
(Merci Pierre pour le partage)
Une explication très clair du fonctionnement des executions asynchrones avec Node.js.
La plupart des opérations de type I/O (lire un fichier, faire une requête http, etc) sont réalisées en parallèle du reste du code dans une pool de thread gérée par la libuv.
Cela permet de ne pas bloquer le thread principal en attendant le retour d'une requête HTTP (qui est très long comparé à executer du code ou récupérer une donnée en RAM)
(Merci Ludo pour le partage)
De bon conseils pour créer des types, notamment des union types pour être sur de manipuler des objets correctes.
Plutôt que de faire ça
type Event = {
name: 'CREATE' | 'DELETE';
id?: string;
content?: string;
}Faites plutôt:
type EventCreate = {
name: 'CREATE';
content: string;
}
type EventDelete = {
name: 'DELETE';
id: string;
}
type Event = EventCreate | EventDelete;
Un document interne technique la manière d'optimiser la destructuration d'array qui est massivement utilisé dans les React Hook.
C'est intéressant de voir que la destructuration d'objets était plus légère et rapide que la destructuration d'array (64 bytes d'instructions vs 305).
La destructuration d'objet est même plus rapide que de faire:
const array = useState(),
count = array[0],
setCount = array[1];Ces différences sont très légères et uniquement observées sur le bytecode non optimisé.
Une alternative au compilateur officiel TSC pour Typescript.
C'est beaucoup plus rapide (~100x plus rapide) car:
- écrit en C++
- écrit uniquement pour les versions récentes de TS
- cache des fichiers compilés
Il utilise un bytecode intermédiaire pour représenter le typescript et conserve un cache pour ne prendre en compte que les dernières modifications.
Par contre toutes les fonctionnalités ne sont pas supportées.
(Merci Sébastien pour le partage)
Une librairie pour dessiner des graphiques qui reste assez méconnue malgré ses features et ses performances.
Contrairement à beaucoup de lib (ApexChart, Chart.js), Vizzu utilise des canvas pour dessiner les graphs.
Il y a aussi de très belles animations natives :-)
Il ne faut pas forcément se focaliser sur la performance à tout prix ou sur la maintenabilité à tout prix.
C'est toujours une histoire de compromis entre les deux.
J'aime beaucoup cette citation qui me fait pensé au mécanisme de gestion mémoire de Rust:
Sharing state is fine, so long as we don’t mutate it.
Mutating state is fine, so long as we don’t share it.
Le processus de stringification de typescript-json est beaucoup plus rapide car la librairie se base sur une liste de types pour les serialiser.
En gros à l'étape de compilation, la librairie va générer le code Javascript pour sérialiser exactement toutes les propriétés d'un objet typé donc on s'épargne les étapes de parcourir de l'objet et de découverte des types des propriétés.
Par contre on ne peut traiter que des payloads ayant un type défini à l'avance.
Exemple de code généré pour un type ({ name: string, age: number):
const $string = typescript_json_1.default.stringify.string;
const $number = typescript_json_1.default.stringify.number;
const $so = [
input => `{"name":${$string(input.name)},"age":${$number(input.age)}}`
];
return $so[0](http://input);
Un bundler/builder Javascript pour remplacer Webpack, c'est écrit en Rust et ils affichent des performances de 5 à 10 fois supérieurs.
Pour l'instant c'est que pour les projets Next.js ou Vite.
10 challenges pour comprendre les promises en Javascript
L'auteur d'une lib de CSS in JS pour React explique les désavantages de ce fonctionnement.
Les deux principaux désavantages sont le poids supplémentaire des libs nécessaires et l'impact non négligeable sur les performances de rendu.
Après la lib offre quand même une DX très confortable donc à chacun de faire ses compromis.
(Merci Ludo pour le partage)
Un repo Github ou j'ai rassemblé pas mal de ressources à propos du fonctionnement des moteurs Javascript (principalement v8)
C'est toujours bien de comprendre comment est executé le code que l'on écrit, pour le debuguer plus efficacement mais aussi pour l'optimiser quand on en a besoin !
Au programme:
- Hidden Classes
- Inline Cache
- Closures
- Function Polymorphisme et Mégamorphisme
- Interpreteur et Compilateur spéculatif
- Micro Benchmark
Certains articles sont assez complexes mais en règle général ça reste abordable.
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 management de repo Javascript.
Dans le même genre que Lerna ou Turborepo, c'est écrit en Rush et ça permet d'automatiser les builds (entre autre)
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é.
Un package NPM qui propose aux développeurs un moyen de lutter contre les failles CSRF n'étais pas correctement conçu et du coup rendait possible des failles CSRF.
Autre chose, le package utilisait aussi SHA1 qui est déprécié..
L'article décrit le fonctionnement de la vulnérabilité.