Revue de presse Inno #11

Développement Web

Bien démarrer avec le rendu côté serveur avec Angular

Par Kévin Barralon

Cette semaine, nous avons mis en ligne un tutoriel pour les développeurs qui utilisent le framework JavaScript Angular. Ce tutoriel a pour but de les aider à initialiser un projet Angular avec le rendu côté serveur pré-configuré. L’intérêt de la mise en place d’un rendu côté serveur permet de rendre le contenu d’une application lisible par les robots (Google, Facebook, Twitter) mais aussi d’améliorer les performances d’une application Angular, avec le transfert d’état entre le côté serveur et le côté client. Ces fonctionnalités étant une nouveauté du framework, la dernière version de Angular (v5) fut utilisée dans ce tutoriel.

Vous pouvez accéder à une version plus complète de ce tutoriel en lisant cet article : Comment créer une application Angular avec le rendu côté serveur ?

Emballer vos applis JavaScript avec Parcel

Par Jacob Cook

L’écosystème JavaScript est connu pour son évolution rapide et constante. Le développement d’une application moderne en JavaScript nécessite une panoplie d’outils et librairies, y compris des “bundlers”, qui gèrent la génération et emballement des “assets” nécessaires lors de la création d’une site Web. Jusqu’à présent, il y a eu deux grands projets de “bundlers” : Browserify et Webpack. Ils ne sont pas vraiment connus pour être faciles à apprendre ou à utiliser. On n’a qu’à aller chercher Google pour savoir “pourquoi est-ce que Webpack est si… lent ? …compliqué ?” et ainsi de suite.

Il est clair que l’écosystème a besoin d’un coup de pouce à ce sujet. Il y a un nouveau projet qui compte justement donner ce coup de pouce, et il s’appelle Parcel. Il fait pas mal les mêmes choses que Webpack à la base (code splitting, transpilation et transformation, hot module replacement) mais avec très peu de “bootstrapping” à faire, et pas beaucoup d’options ou de configurations à écrire pour assurer son bon fonctionnement. Il utilise aussi un système de compilation à multi-cœur, ce qui lui permet d’être bien mieux optimisé en terme de performance et d’utilisation CPU de votre ordinateur à travers plusieurs “workers”.

Reste à voir si Parcel sera couronné le “bundler” JavaScript par excellence, mais si les premiers retours d’utilisations se confirment, il apportera une bouffée d’air frais aux développeurs Web qui ne veulent que démarrer leur prochain projet moderne avec rapidité et efficacité. Et sans avoir besoin d’aspirine ! Pour en savoir plus sur Parcel : https://parceljs.org/

Pause Hivernale !

Merci de nous avoir suivi pendant ces 11 numéros. Toute l’équipe vous souhaite un joyeux temps des fêtes.

On se revoit en Janvier 2018 !
Votre équipe Inno Hebdo

Comment créer une application Angular avec le rendu côté serveur ?

Gestion du rendu côté serveur : Une nouveauté Angular imposant un défi

Angular est un framework utilisant le langage de programmation TypeScript. La version 5 a été mise en ligne en novembre 2017, avec de nouvelles fonctionnalités et corrections de bugs. Cette dernière version est accompagnée de l’outil en ligne de commande Angular CLI, mais aussi de nouveautés  attendues et réellement plébiscitées par la communauté, comme la gestion du rendu côté serveur.

Un des problèmes récurrents que l’on peut rencontrer lorsque l’on met en place un site web avec une librairie moderne (Angular, React, Vue.js, etc.) est que, de manière générale, les robots ne pourront pas lire votre site. Par conséquent, si vous souhaitez partager votre article sur Facebook, ou simplement être bien référencé sur les moteurs de recherche, la partie risque d’être compliquée (bien que dans le cas de Google, il semblerait que leurs robots soient capable de lire des pages générées par Javascript depuis récemment).

La raison est simple, la plupart des robots ne savent pas à quel moment votre page sera entièrement générée par Javascript. Par conséquent, ils ne seront en mesure de lire qu’une infime partie de votre HTML, à savoir, bien souvent, un petit ‘Loading…’ pas très explicite !

Comment peut-on alors créer une application Angular avec le rendu côté serveur ?

Angular CLI

Pour pallier à ce problème, Angular CLI (l’outil qui aide à la génération d’une application Angular) peut venir à la rescousse. Également, avec la version 5 d’Angular, il est désormais possible de gérer le transfert d’état serveur vers le client. Par exemple, une application qui fait une requête à une API Rest ne fera pas la même requête deux fois (une fois côté serveur, une autre fois côté client) mais transférera le résultat côté serveur au client. Nous allons étudier ces deux cas successivement afin de pouvoir bien démarrer une application avec le rendu côté serveur.

Comment initier le projet Angular?

Démarrons en installant l’outil Angular CLI :
npm i -g @angular/cli

On initialise ensuite notre projet :
ng new ssr-app style=scss # Parce que c'est mieux avec le SCSS

On va dans le répertoire de l’application générée et on lance le serveur de développement :

cd ssr-app
ng serve

Allez sur http://localhost:4200/ et enjoy ! Maintenant, nous devons configurer la gestion du rendu côté serveur.

Comment configurer le rendu côté serveur?

Commençons par installer le package platform-server : npm i -S @angular/platform-server

Dans le fichier .angular-cli.json à la racine du projet, il faut ajouter dans la partie « apps », la configuration suivante :

{
   "name": "universal",
   "platform": "server",
   "root": "src",
   "outDir": "dist-server",
   "main": "main.server.ts",
   "tsconfig": "tsconfig.server.json",
   "environmentSource": "environments/environment.ts",
   "environments": {
      "dev": "environments/environment.ts",
      "prod": "environments/environment.prod.ts"
   }
}

Dans notre dossier src/app, on a désormais besoin d’un fichier app.server.module.ts à côté de notre fichier app.module.ts. Ce sera notre point d’entrée pour notre application côté serveur. Son contenu :

import {NgModule} from '@angular/core';
import {ServerModule} from '@angular/platform-server';

import {AppModule} from './app.module';
import {AppComponent} from './app.component';

@NgModule({
   imports: [
      AppModule,
      ServerModule
   ],
   bootstrap: [AppComponent]
})
export class AppServerModule {
}

Le fichier hérite simplement des modules du fichier app.module.ts et ajoute le module ServerModule.

Quant au fichier main.server.js renseigné dans le .angular-cli.json, nous devons le créer à côté du fichier main.ts dans le répertoire src/ avec le contenu suivant :

import {enableProdMode} from '@angular/core';
export {AppServerModule} from './app/app.server.module';

enableProdMode();

Nous devons également créer un fichier tsconfig.app.server.json pour la compilation de TypeScript à côté du tsconfig.app.json dans le même répertoire :

{
   "extends": "./tsconfig.app.json",
   "compilerOptions": {
      "outDir": "../out-tsc/server",
      "module": "commonjs"
   },
   "exclude": [
      "test.ts",
      "**/*.spec.ts"
   ],
   "angularCompilerOptions": {
      "entryModule": "app/app.server.module#AppServerModule"
   }
}

Dans le répertoire src/app, il nous faut désormais modifier le fichier app.module.ts en ajoutant une méthode à notre module BrowserModule :

import {BrowserModule} from '@angular/platform-browser';
import {NgModule} from '@angular/core';
import {AppComponent} from './app.component';

@NgModule({
   declarations: [
      AppComponent
   ],
   imports: [
      BrowserModule.withServerTransition({ appId: 'universal' })
   ],
   providers: [],
   bootstrap: [AppComponent]
})
export class AppModule {
}

On peut désormais builder notre application côté serveur/côté client. Pour cela, rajoutons une ligne dans les scripts de notre package.json :

"scripts": {
   ...
   "universal": "ng build --prod && ng build --prod --app universal --output-hashing=none",
   ...
}

A quoi sert cette commande ? Tout simplement à générer d’une part, une build côté client et, d’une autre part, une build côté serveur (avec la référence à notre app configurée dans le fichier .angular-cli.json). Pour le côté serveur on enlève la création d’un hash sur le fichier généré main.bundle.js pour pouvoir y faire référence plus tard.

Si on lance la commande npm run universal, on obtient bien nos deux builds dans deux fichiers respectifs dist/ et dist-server/.

Désormais, on souhaite pouvoir lancer notre serveur. Pour l’instant, le package Universal d’Angular ne supporte que Node.js et ASP.NET. Nous allons écrire notre serveur en Node.js.

Il faut tout d’abord installer le package @nguniversal/express-engine qui permettra de bootstraper notre serveur Node.js avec le framework Express. Il suffit donc de lancer la commande npm i -S @nguniversal/express-engine.

On va ensuite écrire un fichier server.js à la racine de notre projet avec ce contenu :

require('zone.js/dist/zone-node');

const express = require('express');
const ngUniversal = require('@nguniversal/express-engine');

/**
* On charge le seul fichier de notre build côté serveur
*/
const bootstrap = require('./dist-server/main.bundle');

/**
* On crée motre instance Express
*/
const app = express();

app.get('/', (req, res) => res.render('index', {req, res}));

/**
* Obtient les fichiers statics provenant de la build dist/
*/
app.use(express.static(`${__dirname}/dist`));

/**
* Configuration de Express Engine
*/
app.engine('html', ngUniversal.ngExpressEngine({
   bootstrap: bootstrap.AppServerModuleNgFactory
}));
app.set('view engine', 'html');
app.set('views', 'dist');

/**
* Toutes les URLs renvoient à l'index.html du répertoire dist/
* Angular se charge se rediriger vers les bonnes routes
*/
app.get('*', (req, res) => res.render('index', {req, res}));

/**
* On lance notre serveur
*/
app.listen(3000, () => console.log(`Listening on http://localhost:3000`));

Champagne ! Nous avons enfin configuré notre application Angular ainsi que notre serveur Node.js.

Lancez le serveur en tapant ‘node server.js’ et accédez à l’URL http://localhost:3000. Votre page est générée côté serveur au lancement, puis prise en charge par la build côté client une fois chargée. Si vous désactivez le Javascript de votre navigateur, miracle ! Votre page est tout de même générée grâce à notre configuration.

Comment transférer l’état de l’application ?

Bien que notre application fonctionne parfaitement avec cette configuration, celle-ci n’est pas complètement optimale.

Si votre application nécessite des requêtes via une API Rest par exemple, celles-ci seront effectuées deux fois au lieu d’une. En effet, si le serveur est sollicité pour effectuer une requête, le navigateur ne le sait pas et effectuera cette même requête une seconde fois lorsque le côté serveur prendra le relai.

Pour l’exemple, nous allons commencer par ajouter le HttpClientModule dans notre app.module.ts et notre app.server.module.ts (l’idéal serait d’avoir un fichier de modules en commun, mais je vous laisse la liberté de le faire !) :

import {HttpClientModule} from '@angular/common/http';

@NgModule({
   ...
   imports: [
      ...
      HttpClientModule
   ],
   ...
})
export class AppModule {
}

Allons dans notre app.component.ts et supprimons le contenu que nous allons remplacer par :

import {Component, OnInit} from '@angular/core';
import {HttpClient} from '@angular/common/http';

@Component({
   selector: 'app-root',
   templateUrl: './app.component.html'
})
export class AppComponent implements OnInit {
   image: any;

   constructor(private http: HttpClient) {
}

ngOnInit() {
   this.http.get('http://www.splashbase.co/api/v1/images/random')
      .subscribe(data => this.image = data);
    }
}

Nous nous chargeons d’afficher une image random récupérée via une API Rest.

Pour le rendu, éditons notre fichier app.component.html que nous remplacerons par cette unique balise :

< img *ngIf="image" [src]="image.url" >

Cette image sera donc le résultat de notre requête à l’API.

Si nous démarrons une build avec npm run universal et que nous lançons notre serveur avec ‘node server.js’, nous avons bien notre page qui fonctionne correctement. Petit bémol : l’image apparaît quelques millisecondes et est remplacée par une autre image.

La raison est le même que précédemment : une requête est faite côté serveur, et une autre est faite côté client une fois la page chargée. Le requête côté client est donc inutile.

L’idée est donc de transférer l’état de notre requête vers le côté client afin de ne pas multiplier les requêtes inutiles.

Pour cela, nous allons importer le ServerTransferStateModule dans notre app.server.module.ts et le BrowserTransferStateModule dans notre app.module.ts :

/* app.server.module.ts */
import {ServerTransferStateModule} from '@angular/platform-server';

@NgModule({
   imports: [
      ServerTransferStateModule /* Ici ! */
   ],
   bootstrap: [AppComponent],
})
export class AppServerModule {}

/* app.module.ts */
import {BrowserTransferStateModule} from '@angular/platform-browser'

@NgModule({
imports: [
   ...
   BrowserTransferStateModule /* Ici ! */
   ],
   bootstrap: [AppComponent],
})
export class AppServerModule {}

Une fois la configuration effectuée, on peut se rendre dans notre fichier app.component.ts. On crée ensuite une clef avant la déclaration de notre Class et on ajoute TransferState dans notre constructeur :

import {makeStateKey, TransferState} from '@angular/platform-browser';

const IMAGE_KEY = makeStateKey('image');

@Component({
   selector: 'app-root',
   templateUrl: './app.component.html'
})
export class AppComponent implements OnInit {
   ...
   constructor(private http: HttpClient,
      private state: TransferState) {
   }
...
}

Ensuite on modifie notre méthode ngOnInit de cette manière :

ngOnInit() {
   const image: any = this.state.get(IMAGE_KEY, null);

   /**
   * Si l'image n'est pac contenue dans notre clef, on effectue la requête
   */
   if (!image) {
      this.http.get('http://www.splashbase.co/api/v1/images/random')
         .subscribe(data =&gt; {
            this.image = data;
            this.state.set(IMAGE_KEY, data as any);
          });
   }

   /**
   * Sinon, on récupère le contenu de notre clef
   */
   else {
      this.image = image;
   }
}

On lance ensuite une build de notre application ainsi que notre serveur :

npm run universal
node server.js

Désormais, le contenu de l’image est transféré du serveur au client et la requête n’est effectuée qu’une fois !

Conclusion

Vous avez maintenant toutes les cartes en mains pour démarrer une application Angular avec le rendu côté serveur configuré.

Il suffit maintenant de faire attention à ne pas appeler des objets disponibles uniquement sur le navigateur (comme window par exemple) sans condition.

Par exemple pour vérifier que l’on est côté client ou non :

import { PLATFORM_ID, Inject } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';

   constructor(
      @Inject(PLATFORM_ID) private platformId: Object,
      @Inject(APP_ID) private appId: string) {
      if (isPlatformBrowser(platformId)) {
         console.log('Je suis appelé côté client !')
      }
    }

Toutes ces astuces simplifieront vos développements Angular avec tous les avantages du rendu côté serveur !

Revue de presse Inno #7

Mobile

Protocoles génériques et Type Erasure en Swift

Avec Swift, vous pouvez définir des protocoles en leur associant un ou plusieurs types génériques. Ces types sont définis en utilisant le mot-clé « associatedtype ».  L’appellation « type générique » est un peu usurpée ici, nous devrions plutôt parler d’un espace réservé pour un type inconnu. En effet, nous verrons que de tels protocoles n’offrent pas une grande souplesse d’utilisation lorsqu’il s’agit de réellement les considérer comme génériques.
En savoir plus :

Développement Web

Django 2.0 Release Candidate désormais disponible

Par Kévin Barralon

Le framework Django dont la prochaine version 2.0 est prévue autour du 1er décembre vient de publier sa version Candidate ce jeudi 15 novembre. Contrairement à ce que l’on pourrait penser, cette nouvelle version ne va pas apporter d’incompatibilités majeures au sein du framework. Les changements seront donc du même acabit que les versions précédentes.

Cependant, le changement important de cette version 2 sera l’incompatibilité avec Python 2.7, dont la fin du support est programmée pour 2020. Django 2.0 supportera donc au minimum la version 3.4, même s’il est chaudement recommandé de passer directement à la dernière version de Python (3.6 actuellement).

Routage d’URL

Au niveau des nouveautés, la nouvelle fonction django.urls.path() rend la syntaxe du routage des URL beaucoup plus simple et lisible. Ainsi, au lieu d’écrire : url(r'^articles/(?P[0-9]{4})/$', views.year_archive)

vous pourrez écrire : path('articles/<int:year>/', views.year_archive)

Cette nouvelle syntaxe permettra également de recevoir dans la vue (views) les arguments avec le typage défini (un nombre entier dans le cas de year au lieu d’une string).

Dans cet exemple, il n’y a toutefois pas de possibilité d’ajouter une contrainte (une année à 4 chiffres dans notre exemple). Pour cela, la fonction actuelle django.conf.urls.url() sera remplacée par django.urls.re_path(), qui permettra de conserver la possibilité de mettre des expressions régulières dans la définition de l’URL.

La fonction django.conf.urls.include() sera également directement disponible via django.urls. Pour pourrez ainsi importer vos modules de la manière suivante from django.urls import include, path.

Autres nouveautés

  • Pour les autres nouveautés : L’admin de Django 2.0 sera désormais responsive, donc adapté aux appareils mobiles.
  • Une nouvelle classe Window a été ajoutée afin de permettre l’utilisation du mot-clé OVER dans les requêtes SQL.
  • Une liste de tous les ajouts mineurs est disponible dans le communiqué officiel.
En savoir plus :

Déployer des services entiers avec Docker Swarm et Gitlab CI

Chez Savoir-faire Linux, je travaille (entre autres) sur l’infrastructure de déploiement pour plusieurs services que l’on héberge, et je suis toujours à l’affût de méthodes innovantes pour améliorer notre pratique DevOps. Présentement, le système de déploiement est axé autour de l’utilisation de Ansible pour « provisioner » un service dans une machine virtuelle, et l’ajuster au besoin après. Mais pour améliorer la stabilité de nos builds, de déploiements et l’agilité avec laquelle on peut faire des déploiements en continu, nous regardons d’autres approches DevOps, comme l’utilisation des containeurs Docker hébergés dans un Registry et déployés par un outil comme Gitlab CI.
Parmi les outils disponibles pour déployer une architecture de « microservice » (créée avec docker-compose), nous trouvons Docker Swarm. En utilisant un certain nombre de serveurs proprement configuré, on peut déployer un « stack » de containeurs avec un simple docker stack deploy. Docker va choisir par la suite la meilleure configuration pour le déploiement des différents containeurs à travers l’infrastructure du Swarm. Il va même aller jusqu’à configurer la réseautique entre les containeurs automatiquement, comme si tu utilisais docker-compose sur un ordinateur en local.
 
La meilleure partie, c’est le fait que ça marche bien avec notre système d’automatisation des builds déjà existant, GitLab CI. Nous pouvons faire le pipeline « build – test – release – deploy » à travers toute notre infrastructure avec GitLab CI et le GitLab Container Registry. Il y a toujours des parties casse-têtes à régler, mais ce système représente déjà un grand bond vers l’avant pour la simplicité et l’efficacité de notre pratique DevOps.
En savoir plus :

Revue de presse Inno #6

Design

Atomic Design

Par Patrick Bracquart 

Depuis l’avènement du web, on parle de conception de pages web. Ce terme, hérité du domaine imprimé, démontre bien la considération du contenu web depuis les années 90 : une architecture composée de pages consultables, comme un livre. 
Or, depuis maintenant quelques années, la multitude de plateformes disponibles pour consulter du contenu web ne cesse d’augmenter et de se complexifier. De l’ordinateur au mobile en passant par la télévision ou encore les montres intelligentes, il est devenu clair que le concept de design et de structure de pages web est obsolète. 

 

L’atomic design, terme inventé par Brad Frost, est une nouvelle méthodologie de design. Au lieu de penser son contenu comme une page, chaque élément de design est conçu en partant du plus petit élément (comme un call to action) vers un ensemble plus grand. On part de l’atome pour créer une molécule et elles s’assemble pour créer un organisme web cohérent et modulable. 

Chaque atome étant placé individuellement dans une librairie, l’atomic design est un gain de temps et de cohérence en plus d’une mise à jour simplifiée.

Pour en savoir plus :

Développement web

Makefile ou comment éviter de réinventer la roue

Par Samuel Sirois

Après m’être absenté pendant quelques années de la partie frontale des applications web, j’ai été récemment appelé à replonger dans ce monde à travers deux projets auxquels je collabore. Une belle occasion de revisiter mes idées préconçues et mes vieilles habitudes de travail puisqu’une base de code déjà existante et utilisant les derniers outils à la mode est présente sur mon poste après le git clone initial.

Ouf ! Ça bouge vite sur la première ligne ! De nouvelles versions d’ECMAScript supportées par les clients Web modernes, une plénitude de pseudo-langages basés sur JavaScript, la multiplication des pré-processeurs CSS… Que dire de tout ces moteurs de production maintenant disponibles spécifiquement développés par et pour les développeuses et développeurs JavaScript ?

Avec toutes ces merveilles, ces derniers (les moteurs de productions) deviennent essentiels pour éviter que l’effort nécessaire pour agréger, minifier, lier, compiler ?!, tous ces fichiers ne viennent pas annuler les gains en efficacité d’avoir dorénavant les outils nécessaires à la création d’applications web modernes.

Je me questionne tout de même à savoir s’il n’y a pas eu un petit manque de communication entre celles et ceux qui ont plus récemment eu ce besoin dans leurs projets (les développeuses et développeurs de la partie frontale) et celles et ceux qui ont déjà eu ces mêmes besoins et qui ont trouvé une solution (pas la seule) à ce problème depuis les années soixante-dix !

Je n’ai jamais ressenti le besoin d’utiliser ces outils modernes, connaissant déjà Make et ayant déjà été confronté à de nouvelles solutions à la mode à la fin du siècle dernier, j’ai finalement fait marche arrière pour revenir à ce qui fonctionnait déjà. Évidemment, je me fais un devoir de rédiger manuellement les Makefiles des projets auxquels je participe et je n’hésite pas à entretenir cet outil.

Réinventer la roue, pour refaire les mêmes erreurs ou pour vraiment améliorer la situation ? Quelques liens intéressants pour vous faire votre propre opinion :

Contribution

Des contributions au Inno Hackest

Devant le succès des après-midis de contributions, l’équipe a décidé de renforcer l’activité et de bonifier sa formule. Dorénavant, ces après-midis auront lieu aux deux semaines sous le nom de « Hackfest ».

 

Nos premiers Hackfest

 

 

Par petits groupes de personnes, jamais tout seul, nos SFLiens ont l’opportunité de se former sur de nouvelles technologies, de contribuer à des projets qui leur tiennent à cœur ou à travailler sur de nouveaux « side project ».
On y retrouve pêle-mêle des initiations à la réalité virtuelle comme la réalisation d’une simulation de chute de Domino avec le moteur physique Unity et l’Oculus Rift, un atelier sur la technologie Blockchain et l’étude du cas concret de l’annuaire des usernames de Ring, la réalisation de POC et de prototypes par exemple sur des bases de données orientées document.

Review Upgrade

Par Maxime Turcotte

La page du rapport d’analyse de migration de Drupal 8, sur laquelle sont répertoriés les modules qui seront migrés et ceux qui ne le seront pas, avait grand besoin d’une refonte afin d’améliorer l’expérience utilisateur. Durant notre après-midi hackfest, j’ai écrit une première version d’un correctif qui réutilise certains éléments de design du tableau de bord d’administration. Ainsi, en ajoutant simplement quelques icônes, il est beaucoup plus facile de voir d’un seul coup d’œil ce qui requiert notre attention.

Revue de presse Inno #5

Développement Web

Node.js publie la branche 8.x en LTS

Le calendrier de publication de Node.js planifie des mises à jour sur le support à long terme (LTS) chaque octobre normalement, et cette année ne fera pas d’exception. Node.js offre aux développeurs un joyeux cadeau d’Halloween cette année en qualifiant sa version actuelle (8.x) comme une version LTS stable. Cela signifie que les fonctionnalités qui ont été à la fine pointe du développement depuis le début de l’année 2016 ont finalement été rendues disponibles aux utilisateurs qui ont besoin de l’environnement stable et bien testé qui leur est offert par une version LTS.
 

Les nouvelles fonctionnalités très attendues de Node.js 8.x incluent le support au complet pour async / await dans le noyau même de Node.js, des mises à jour au moteur V8, une implémentation HTTP / 2, une nouvelle version de NPM qui permet le versionnage des paquets par épinglage avec les lockfiles, et bien plus encore.

Pour en savoir plus :

Mobile

Firebase Dev Summit

Le Dev Summit de Firebase vient de se terminer et plusieurs annonces ont été faites:
 
Suite au rachat de Fabric par Google, Crashlytics va être intégré à la console Firebase. Ce nouveau système de remontée de crash bénéficiera d’accès aux autres services de Firebase, notamment aux Cloud Functions; ce sont des fonctions (lambdas) déclenchées sur la base de trigger interne à Firebase ou externe par le biais d’une API REST.
L’avantage ici sera de pouvoir déclencher une Cloud Function en réponse à certains crashs remontés. Un crash dans le flow principal d’utilisation de l’app pourrait déclencher l’envoi d’un email à toute l’équipe pour accélérer sa résolution. Une CloudFunction pourrait également se charger de créer une demande sur un outil de gestion.  

Google met le machine learning à l’oeuvre avec un nouveau service, Predictions permettant d’identifier des groupes d’utilisateurs en se basant sur leurs utilisation de l’application. Cela permet ensuite via Firebase de proposer à ces groupes des offres ou des fonctionnalités exclusives afin de conserver leur engagement.
Pour les autres annonces c’est par ici: