# Retour sur les nouveautés d’ES2018 [JavaScript, ES2018]

par Xavier Calland

La neuvième édition de la norme ECMAScript, connue officiellement sous le nom de ECMAScript 2018 (ou ES2018 en abrégé), a été publiée en juin 2018.
Le site CSS-Tricks nous présente les nouveautés de cette version qu’il ne fallait pas rater.

# Retour sur les «nouveautés» d’ES2015 ? [Javascript, ES2015, Traits, for..of]

par Guillaume Poittevin

Ces deux articles m’ont paru très intéressants. Certes les fonctionnalités présentées sont moins récentes que celles de l’article précédent, mais de nombreux développeurs ne les maîtrisent pas forcément. Pourtant ces ajouts résolvent des manquements souvent reprochés à Javascript. Découvrez les traits et leur utilisation dans les boucles for…of. Bonne lecture.

# PostgreSQL désigné SGBD de l’année 2018 [PostgreSQL, SGBD]

par Aurélien Morlé

Comme chaque année maintenant, le site DB-Engines, spécialisé dans le classement des moteurs de base de données, a livré son classement pour l’année 2018. Sur les 343 SGBD qui étaient en course pour le titre, c’est PostgreSQL (+79.93) qui pour la 2ème année consécutive a été élu meilleur SGBD de l’année devant MongoDb (+56.24) et Redis (+25.88) qui complètent le podium.

Le titre de SGBD de l’année est décerné à celui qui enregistre la plus forte hausse de popularité au cours de l’année. Vous pouvez retrouver la méthodologie de calcul sur DB-Engines

Cette hausse de popularité est aussi liée aux nouveautés des dernières versions notamment pour le big data.

# GraphQL à la conquête du monde … ou pas [GraphQL, REST]

par Xavier Calland

C’est la techno du moment, tout le monde en parle et elle devrait changer notre manière de développer des applications web et des API, je veux bien sûr parler de GraphQL.
On voit fleurir un peu partout sur le web des articles faisant l’éloge de GraphQL, expliquant comment elle signe la mort de nos APIs REST.
Mais qu’en est-il vraiment ? Est-ce que les promesses de GraphQL sont vraiment au rendez-vous ?

Chez Atol CD, nous avons actuellement plusieurs projets pour lesquels nous utilisons GraphQL à la place d’APIs REST. C’est encore assez récent et nous sommes encore en train de nous familiariser avec cette technologie.
Cela dit, voici nos premières impressions :

  • C’est encore jeune et les bonnes pratiques ont du mal à émerger
  • De ce fait, le coût d’entrée est assez élevé aussi bien côté serveur que client
  • La description du schéma est un vrai plus pour la consommation de l’API. Couplé aux outils d’analyse par introspection (comme graphiql ou playground) simplifie l’utilisation de l’API notamment lorsqu’il y a deux équipes distinctes de développement (client et serveur).
  • GraphQL nous semble bien adapté pour développer une API multi-clients dont les besoins ne sont pas identifiables lors du développement de l’API et quand l’accès aux données se fait de manière assez basique (pas de grosses requêtes avec agrégats demandant une optimisation trop poussée, …)
  • Le retour sur investissement est plus discutable pour une API consommée uniquement par une seule application web.

Voici une compilation de quelques avis et retours d’expérience pour se forger son propre avis :

Tweetez
Partagez
Partagez
0 Partages