Spring 5 e Servlet 4 - Il PushBuilder

1. Introduzione

La tecnologia Server Push - parte di HTTP / 2 (RFC 7540) - ci consente di inviare risorse al client in modo proattivo dal lato server. Si tratta di un cambiamento importante rispetto all'approccio basato su pull HTTP / 1.X.

Una delle nuove funzionalità di Spring 5 è il supporto push del server fornito con Jakarta EE 8 Servlet 4.0 API. In questo articolo, esploreremo come utilizzare il server push e integrarlo con i controller Spring MVC .

2. Dipendenza da Maven

Cominciamo definendo le dipendenze che useremo:

 org.springframework spring-webmvc 5.2.8.RELEASE   javax.servlet javax.servlet-api 4.0.0 provided 

Le versioni più recenti di spring-mvc e servlet-api sono disponibili su Maven Central.

3. Requisiti HTTP / 2

Per utilizzare il server push, dobbiamo eseguire la nostra applicazione in un contenitore che supporta HTTP / 2 e l'API Servlet 4.0 . I requisiti di configurazione dei vari contenitori possono essere trovati qui, nel wiki di Spring.

Inoltre, avremo bisogno del supporto HTTP / 2 sul lato client ; ovviamente, la maggior parte dei browser attuali dispone di questo supporto.

4. Caratteristiche di PushBuilder

L' interfaccia PushBuilder è responsabile dell'implementazione del server push. In Spring MVC, possiamo iniettare un PushBuilder come argomento dei metodi annotati con @RequestMapping .

A questo punto, è importante considerare che, se il client non dispone del supporto HTTP / 2, il riferimento verrà inviato come null .

Ecco l'API principale offerta dall'interfaccia PushBuilder :

  • path (String path) - indica la risorsa che stiamo per inviare
  • push () - invia la risorsa al client
  • addHeader (String name, String value) - indica l'intestazione che useremo per la risorsa inviata

5. Esempio rapido

Per dimostrare l'integrazione, creeremo la pagina demo.jsp con una risorsa - logo.png :

     PushBuilder demo   PushBuilder demo

Esporremo anche due endpoint con il controller PushController , uno che utilizza il server push e un altro che non lo fa:

@Controller public class PushController { @GetMapping(path = "/demoWithPush") public String demoWithPush(PushBuilder pushBuilder) { if (null != pushBuilder) { pushBuilder.path("resources/logo.png").push(); } return "demo"; } @GetMapping(path = "/demoWithoutPush") public String demoWithoutPush() { return "demo"; } }

Utilizzando gli strumenti di sviluppo di Chrome, possiamo vedere le differenze chiamando entrambi gli endpoint.

Quando chiamiamo il metodo demoWithoutPush , la vista e la risorsa vengono pubblicate e utilizzate dal client utilizzando la tecnologia pull:

Quando chiamiamo il metodo demoWithPush , possiamo vedere l'uso del server push e come la risorsa viene consegnata in anticipo dal server, con un tempo di caricamento inferiore:

La tecnologia server push può migliorare il tempo di caricamento delle pagine delle nostre applicazioni in molti scenari. Detto questo, dobbiamo considerare che, sebbene riduciamo la latenza, possiamo aumentare la larghezza di banda, a seconda del numero di risorse che serviamo.

È anche una buona idea combinare questa tecnologia con altre strategie come Caching, Resource Minification e CDN ed eseguire test delle prestazioni sulla nostra applicazione per determinare gli endpoint ideali per l'utilizzo del server push.

6. Conclusione

In questo breve tutorial, abbiamo visto un esempio di come utilizzare la tecnologia server push con Spring MVC utilizzando l' interfaccia PushBuilder e abbiamo confrontato i tempi di caricamento durante l'utilizzo rispetto alla tecnologia pull standard.

Come sempre, il codice sorgente è disponibile su GitHub.