Nous espérons que vous avez passé de bonnes vacances
Ici à Kuzzle toute l'équipe en a profité pour se ressourcer et profiter du soleil
Cependant nous avons aussi pleins de nouvelles fonctionnalités à vous faire découvrir pour la rentrée !
Voici un résumé des nouvelles fonctionnalités sur nos différents projets.
Lire cet article en Anglais: https://blog.kuzzle.io/equinox-release
La version 1.5 est une nouvelle version mineure de Kuzzle avec deux nouvelles fonctionnalités et pleins d'améliorations.
Il est à présent possible de définir des utilisateurs, profiles et rôles qui seront chargés au démarrage de Kuzzle.
Le fonctionnement est le même que pour le chargement de mappings et de données.
Ces utilisateurs, profiles et droits doivent être définis dans un fichier JSON ayant la structure suivante:
{ "roles": { "role-id": { /* role definition */ } }, "profiles": { "profile-id": { /* profile definition */ } }, "users": { "user-id": { /* user definition */ } }
Ce fichier doit ensuite être passé en paramètre à la ligne de commande pour démarrer Kuzzle:
./bin/kuzzle start --securities /chemin/vers/fichier.json
Pour plus d'informations, vous pouvez consulter la documentation associée ou pour les plus techniques directement la pull request.
Beaucoup de nouveautés sur les plugins avec en vrac l'exposition du SDK JS 6 dans le contexte des plugins, une refonte du fichier manifest, node 8 utilisable par défaut et des informations supplémentaires dans les requêtes.
Les développeurs sont habitués à utiliser context.accessors.execute pour exécuter des requêtes vers Kuzzle.
Cette méthode bas niveau est plus compliquée car elle nécessite d'instancier une nouvelle requête et de renseigner tous les champs nécessaires à la main.
Après de nombreuses discussions, nous avons décidé d'exposer le SDK JS 6 à l'intérieur des plugins afin que les développeurs de plugin puissent exploiter la puissance du SDK.
A présent les développeurs de plugins et les utilisateurs du SDK utiliseront la même syntax pour développer avec Kuzzle.
Un exemple avec la création d'un nouveau document dans Kuzzle:
Avant avec context.accessors.execute:
const request = new Request({ controller: 'document' action: 'create', index: 'my-index', collection: 'my-collection', body: { falut: 'world', foo: 42 } }); context.accessors.execute(request)
Maintenant avec le SDK JS 6:
context.accessors.sdk.document.create('my-index', 'my-collection', null, { falut: 'world', foo: 42 });
Notez que le SDK JS 6 est encore en beta. Les instructions pour l'utiliser sont disponibles sur Github.
Il a été conçu pour suivre exactement l'API de Kuzzle. Sa documentation est en cours de rédaction, vous pouvez consulter les contrôleurs déjà documentés ici
Le core-plugin-boilerplate a lui aussi été mis à jour avec un exemple d’utilisation du SDK JS 6 dans une action d’un contrôleur.
Voir la pull request sur Github.
Les plugins doivent à présent posséder un fichier manifest.json en plus du fichier package.json.
Ce fichier contient des informations sur le plugin chargé par Kuzzle:
- name : le nom du plugin
- kuzzleVersion : les versions de Kuzzle supportées au format d'un range semver
Il est possible de voir un exemple de fichier manifest dans le core-plugin-boilerplate.
L'utilisation du fichier package.json pour définir le nom du plugin est déprécié et sera retirée dans Kuzzle v2.
Voir la documentation et la pull request associée.
Une nouvelle image Docker est mise à la disposition des développeurs de plugins: kuzzleio/plugin-dev.
Cette image contient à présent Node.js 8 afin d'exploiter toutes les nouvelles fonctionnalités du langage, notamment les mots clés async et await.
Elle est la nouvelle image par défaut du core-plugin-boilerplate que nous conseillons d’utiliser comme base au développement d'un nouveau plugin.
L'objet Request contient maintenant des informations sur la connexion utilisée.
On peut notamment retrouver le type de protocol utilisé request.context.connection.protocol, les adresses ips du client request.context.connection.ips.
Chaque protocol peut exposer des informations supplémentaires dans le champ request.context.connection.misc. Par exemple le protocol HTTP expose ainsi l'url et les headers de la requête d'origine.
Voir la pull request sur Github.
L'image officiel de Kuzzle (kuzzleio/kuzzle) utilise maintenant Node.js 8 par défaut.
Le support de Kuzzle avec Node.js 8 se terminera en même temps que le support LTS de Node, c'est à dire en décembre 2019 (Voir https://github.com/nodejs/Release).
Le support de Node.js 6 lui sera assuré de la même façon jusqu'en avril 2019.
Kuzzle est officiellement supporté sur macOS!
A présent les utilisateurs de macOS peuvent utiliser le script d’installation automatique de Kuzzle pour commencer à l’utiliser sur leur machine.
Il suffit simplement d’ouvrir votre terminal favori et de taper:
bash -c "$(curl http://get.kuzzle.io/)"
Chez Kuzzle nous prenons très à coeur le confort de nos développeur et nous faisons tout notre possible pour garantir l’accessibilité et le bon fonctionnement de nos produits à tous.
C’est dans cette optique que nous avons mis en place une batterie de tests automatisés pour vérifier le bon fonctionnement de notre script d’installation avec différents systèmes d’exploitations. Ces tests sont intégrés dans nos processus d’intégration continue et font l’objet d’un suivi rigoureux.
Pour les plus curieux d’entre vous, vous pouvez aller voir leur fonctionnement sur Github.
Pour ceux d’entre vous qui ne le savent pas encore, Koncorde est le moteur de temps réel développé spécialement pour Kuzzle. Il a été pensé dès le début pour offrir des performances imbattables comparés aux alternatives open-sources existantes.
Aujourd’hui nous publions la version 1.2 de Koncorde qui comporte de nouvelles fonctionnalités sur des mots clés et un très important gain de performances.
Les mots clés exists et son contraire missing sont maintenant utilisables avec une nouvelle syntax simplifié. Pour rappel, le mot clé exists teste l’existence d’une propriété dans un document et le mot clé missing son absence.
L’ancienne syntax a bien sur été conservée afin d’assurer la rétrocompatibilité de Koncorde, cependant son usage est dépréciée et elle sera supprimée lors de la prochaine release majeure.
Imaginons que je souhaite m’abonner en temps réel à des documents contenant une propriété name mais pas de propriété imbriquée driver.license.
Exemple avec l’ancienne syntax:
{ “and”: [ “exists”: { “field”: “name” }, “missing”: { “field”: “driver.license” } ] }
Et avec la nouvelle syntax:
{ “and”: [ “exists”: “name”, “missing”: “driver.license” ] }
L’usage de exists et missing a aussi été étendu aux champs de type tableau. Il est maintenant possible de tester la présence d’un scalaire (int, string, boolean ou null) à l’intérieur d’une propriété de type tableau.
Par exemple pour tester l’existence d’une chaîne de caractères dans une propriété de type tableau:
{ “and”: [ “exists”: “aliases[\”aschen\”]” ] }
Il est bien sur possible d’utiliser ce filtre avec des propriétés imbriqués:
{ “and”: [ “exists”: “school.ages[42]” ] }
Vous pouvez consulter la documentation de Koncorde qui a été entièrement revue pour l’occasion ou la pull request associée sur Github.
Lors de l’implémentation de cette nouvelle fonctionnalité, des optimisations de performances ont été réalisés sur le coeur de Koncorde.
Historiquement Koncorde a été écrit avec Node.js 4, depuis de nombreuses optimisations ont été réalisées sur les performances et les structures de données. Ces gains de performances sont le résultat de l’application des nouveaux standards de Node.js 8, notamment l’utilisation de Map au lieux d’objets javascripts standards.
Ces modifications améliorent les performances de Koncorde de 4000% en moyenne. Cela paraît énorme mais c’est pourtant la vérité. Voila les nouveaux benchmarks de performances:
# Avant Filter count per tested keyword: 10000 > Benchmarking keyword: equals Registration: time = 0.484s, mem = +41MB Matching x 106,992 ops/sec ±2.46% (70 runs sampled) Filters removal: time = 0.02s # Après Filter count per tested keyword: 10000 > Benchmarking keyword: equals Indexation: time = 0.435s, mem = +41MB Matching x 4,006,895 ops/sec ±0.35% (97 runs sampled) Filters removal: time = 0.02s
Les plus curieux d’entre vous peuvent aller regarder les pulls requests associĂ©es sur Github: ici et lĂ
L’Admin Console passe elle en version 2.2.0 avec de nouvelles fonctionnalités et un important remaniement du code !
L'Admin Console s'enrichit de deux nouvelles vues en plus de la vue liste.
La première est une vue de type bloc ou chaque document est présenté sous la forme d'un rectangle.
La deuxième est une carte qui est disponible lorsque la collection contient des document ayant au moins une propriété de type geo_point.
Un geo_point un type de donnée spécial supporté par Elasticsearch, il représente une coordonnée GPS et Kuzzle l’utilise notamment pour faire du geofencing en temps réel.
Chaque document est placé sur la carte en fonction de ses coordonnées GPS. Si la collection possède plusieurs geo_point alors il est possible de choisir celui utilisé par la vue map.
Pour voir les pulls requests associées c’est ici et ici
Nous avons aussi beaucoup travaillé sur les filtres de recherche pour les rendre plus agréables à utiliser.
Ces filtres sont indispensables lorsque l’on souhaite visualiser correctement certains document dans des collections qui en contiennent plusieurs dizaines de milliers.
Les filtres sont maintenant sauvegardés par l’Admin Console même en cas de rechargement de page ou de changement de collection.
Ils sont présents dans l’URL de votre navigateur, ainsi vous pouvez les partager ou les conserver facilement sous la forme de marques pages par exemple.
Voir la pull request sur Github
La plupart des moteurs de recherche proposent une actualisation en temps réel des résultats sans avoir besoin de valider sa recherche.
L’Admin Console propose maintenant la même fonctionnalité pour la recherche simple. Celle-ci s’effectue au fur et à mesure de la recherche et filtre les résultats de la collection en temps réel.
Voir la pull request sur Github
Une collection peut potentiellement contenir plusieurs centaines de propriétés différentes et cela à plusieurs niveaux d’imbrication.
Lors de l’utilisation de filtres complexes sur certaines propriétés, il est plus commode d’avoir une autocompletion sur le nom de ces dernières plutôt que de devoir se remémorer leur nom exact.
Pour plus d’informations c’est sur Github.
Depuis maintenant plusieurs mois, nous travaillons Ă la sortie de nos tout nouveaux SDK.
Ces SDK ont été développé en se rapprochant le plus possible à l’architecture de notre API.
Nous sommes entrain réécrire la documentation pour inclure tous ces nouveaux SDK mais c’est un processus long et coûteux.
En effet, toujours dans un soucis de qualité nous avons décidé de tester individuellement chaque exemple de code de notre documentation afin de toujours s’assurer de leur bon fonctionnement.
Vous pouvez voir les rapports de ces tests dans notre CI: https://travis-ci.org/kuzzleio/documentation-V2/builds/431052204
Nous travaillons également à un article consacré entièrement à notre processus de test des exemples de code de notre documentation pour partager notre expérience.
Je vous ai déjà parlé du SDK JS 6 qui est utilisé par les développeurs de plugins, il est actuellement en version beta.
Pour l’utiliser dans un projet, vous pouvez utiliser la commande suivante avec NPM:
npm i https://github.com/kuzzleio/sdk-javascript#6-beta --save
La documentation n’est pas encore terminée mais vous pouvez déjà vous lancer en lisant le README sur Github. Vous pouvez également consulter la documentation qui est en cours de réalisation à l’adresse https://docs-v2.kuzzle.io/sdk-reference.
Pour les contrôleurs qui ne sont pas encore documentés, vous pouvez simplement vous fier à la doc de l'API de Kuzzle pour le nom des méthodes et les paramètres attendus.
Le SDK PHP 4 est Ă©galement disponible en version beta.
Vous pouvez le tester dans vos projets en l’installant avec la commande suivante:
compose require kuzzleio/kuzzle-sdk:1-dev
La documentation n’est pas encore disponible mais comme pour le SDK JS 6, les noms des classes est des méthodes sont les mêmes que les contrôleurs et actions de l’API.
N’oubliez pas de nous signaler tout bug rencontré sur Github, nous comptons sur vous!
Le SDK GO 1 est à présent officiellement disponible en version 1 sur Github !
Ce SDK est la clé de notre processus de création de SDK dans tous les langages. Ensuite grâce à SWIG, nous pouvons générer des SDK dans les langages de notre choix en un temps record!
Un article entier sera bientôt dédié au fonctionnement de SWIG et à l’utilisation que nous en avons fait à Kuzzle pour industrialiser notre processus de création et de maintenance de SDKs.
Vous pouvez commencer à l’utiliser dans vos projets Go avec la commande suivante:
go get github.com/kuzzleio/sdk-go
Comme pour les autres nouveaux SDK, la documentation partielle est disponible ici mais la structure du SDK reste la même que celle de l’API.
Vous l’avez compris, chez Kuzzle nous aimons assurer la qualité et l’accessibilité de nos produits pour tous. Nous faisons tout notre possible pour fournir des outils de qualité à nos clients et à notre communauté.
Encore une fois, je voudrais remercier l’ensemble de l’équipe Kuzzle qui donne le meilleur d’elle même pour remplir sa mission et fournir un backend accélérant le développement des applications mobiles, web et IoT.
Si vous avez des questions techniques sur Kuzzle ou un autre de nos produits, vous pouvez nous joindre sur Discord ou par email.