Tutoriel pour découvrir les alternatives au mécanisme RPC de GWT

Zakaria Amine

Ce tutoriel se propose de présenter les différentes alternatives au mécanisme RPC utilisé pour faire communiquer la partie cliente de GWT avec la partie serveur.

Pour réagir à ce support de cours, un espace de dialogue vous est proposé sur le forum Commentez .

- Titre : Tutoriel pour découvrir les alternatives au mécanisme RPC de GWT

- Auteur : Zakaria Amine

- Parution : 19 décembre 2016

- Licence : Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright ® 2016 Zakaria Amine. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. RequestBuilder

- III. RestyGwt

- IV. Autorest

- V. Native XmlHTTPRequest (JsInterop)

- VI. Les autres bibliothèques

- VII. Résumé

- VIII. Pour conclure…

- IX. Remerciements

I - Introduction

Pour plusieurs raisons, de nombreux utilisateurs GWT ont abandonné le mécanisme de RPC qui est le moyen standard offert par GWT pour communiquer avec le backend, ou le côté serveur. Ils se sont retrouvés perdus entre RequestBuilder de GWT et les différentes bibliothèques externes qui peuvent convenir ou pas à leur besoin applicatif. L'objectif de ce tutoriel est de faire un comparatif des bibliothèques HTTP/Rest dans GWT dans une tentative de rendre l'image plus claire. Les bibliothèques que nous allons tester au cours de ce post sont : RequestBuilder (fait partie de GWT), RestyGwt, AutoRest et enfin la bibliothèque JavaScript native XmlHttpRequest (en utilisant JsInterop).

II - RequestBuilder

RequestBuilder est la première chose qui vient à l'esprit. Ce module fait partie du noyau GWT et permet la construction et l'exécution d'appel HTTP. L'implémentation de RequestBuilder fait usage de JSNI pour appeler le XmlHttpRequest natif dans le navigateur. L'inconvénient de RequestBuilder est le traitement des données reçues qui sont reçues sous la forme d'une chaîne de caractères (String). Cette partie est entièrement laissée à l'utilisateur, chose qui nécessite du travail supplémentaire.

1. RequestBuilder request = new RequestBuilder(RequestBuilder.GET, "http://localhost:8085/guest");

3. try {

4. request.sendRequest(null, new RequestCallback() {

5. @Override

6. public void onResponseReceived(Request request, Response response) {

7. GWT.log(response.getText());

8. // La réponse est sous la forme d'un String, et donc les données ont besoin de traitements supplémentaires

9. }

11. @Override

12. public void onError(Request request, Throwable exception) {

13. }

14. });

16. } catch (RequestException e) {

17. e.printStackTrace();

18. }

III - RestyGwt

RestyGWT est une solution plus complète, car elle offre la possibilité d'envoyer et de recevoir des objets ce qui semble comme un bon remplacement pour RPC. RestyGwt fonctionne de la même façon que RPC : le développeur définit des interfaces qui sont implémentées au moment de la compilation à l'aide des Générateurs GWT. RestyGwt est l'un des projets GWT les plus populaires sur Github. La bibliothèque offre également plusieurs fonctionnalités telles que les dispatchers, la manipulation de JSONP, la possibilité de créer des annotations personnalisées, et bien d'autres options utiles. Si le développeur veut faire sans création d'interfaces, RestyGWT offre un moyen de faire des requêtes HTTP, mais sans la sérialisation/désérialisation de Json. Voici un simple exemple d'utilisation de RestyGWT :

1. public interface GuestService extends RestService {

3. @Path("http://localhost:8085/guest")

4. @GET

5. public void get(MethodCallback<List<Guest>> callback);

6. }

8. public void onModuleLoad() {

9. GuestService service = GWT.create(GuestService.class);

11. service.get(new MethodCallback<List<Guest>>() {

12. @Override

13. public void onFailure(Method method, Throwable exception) {

14. GWT.log("Request Failed");

15. }

17. @Override

18. public void onSuccess(Method method, List<Guest> response) {

19. response.forEach((g) -> {GWT.log(g.roomNumber);});

20. }

21. });

22. }

Parmi les inconvénients de RestyGwt, il y a la dépendance totale sur les générateurs qui seront omis dans la prochaine version de GWT (3.0). Bien qu'il n'y ait pas d'indicateur que GWT 2.8.0 sera discontinué à ce moment-là, les développeurs qui voudront mettre à niveau vers 3.0 devront faire sans RestyGwt.

IV - Autorest

AutoRest est un projet intéressant. Il fait usage des nouveaux paradigmes de programmation fonctionnelle tels que les flux pour générer les requêtes HTTP. AutoRest fait usage de RxJava-GWT qui est l'adaptation de RxJava à GWT. Pour faire face à l'aspect asynchrone des appels HTTP, AutoRest utilise l'objet Observable, qui est un objet auquel vous pouvez vous abonner, et dès que le résultat est prêt, il vous informera. AutoRest fait également usage de JsInterop afin de sérialiser/désérialiser les objets à partir de/vers des objets Java/Js. Cette méthode est avantageuse parce qu'elle ne repose pas sur des bibliothèques externes, cependant, il existe certaines limites aux objets que vous pouvez sérialiser. Un autre avantage d'AutoRest, l'utilisation des processeurs d'annotation Java (au lieu des générateurs), ce qui rend la bibliothèque plus viable pour l'avenir.

1. @AutoRestGwt @Path("guest") interface GuestService2 {

2. @GET Observable<Guest> get();

3. }

5. static ResourceVisitor osm() {

6. return new RequestResourceBuilder().path("http://localhost:8085/");

7. }

9. public void onModuleLoad() {

10. GuestService2 gs = new GuestService2_RestServiceModel(() -> osm());

11. gs.get().subscribe(n -> {

12. GWT.log(n.guestId+"");

13. });

14. }

AutoRest reste un projet jeune. Il est dans ses versions 0.x (quatre versions jusqu'à présent), et il a encore besoin de temps pour arriver à maturité. AutoRest introduit également du boilerplate code, mais cela reste gérable.

V - Native XmlHTTPRequest (JsInterop)

En côté client GWT, toutes les bibliothèques précédentes utilisent la requête native du navigateur XmlHttpRequest.

Depuis l'introduction de JsInterop, l'interopérabilité entre Java et JavaScript peut être faite différemment. Le développeur peut faire usage des fonctions natives du navigateur comme si elles étaient des classes Java. L'utilisation de la requête JavaScript native XMLHttpRequest directement est aussi une alternative pour faire des appels côté client dans GWT. Cette méthode est certes bas niveau et nécessite plus de configuration, mais elle permet certainement au développeur de contrôler tous les aspects des demandes/réponses. Par exemple, supposons que vous souhaitez définir un type de réponse en tant que blob, ou spécifier le type de demande comme synchrone, vous n'avez aucun moyen de le faire en utilisant les bibliothèques précédentes parce que vous êtes en quelque sorte borné par leurs configurations. Pour gérer l'aspect asynchrone de HTTP, une Promise peut être utilisée. C'est sûr qu'il y a plus de travail à faire sur la sérialisation/désérialisation des données envoyées et reçues, mais l'avantage de cette méthode reste la liberté de configurer tous les aspects de la requête HTTP. Par exemple :

1. // Implemented using JsInterop, can also be used from Elemental 2

2. private final XMLHttpRequest nativeRequest = new XMLHttpRequest();

4. // false means that the request is synchronous which can not be done in other librairies

5. nativeRequest.open("GET", "http://localhost:8085/guest", false);

7. // there are other events such progress, abort, error that are not available in other librairies

8. nativeRequest.addEventListener("load", new Function() {

9. @Override

10. public Object call(JavaScriptObject event) {

11. GWT.log(nativeRequest.responseText);

12. return null;

13. }

14. });

16. nativeRequest.send();

VI - Les autres bibliothèques

Il y a d'autres bibliothèques qu'on n'a pas couvertes dans ce post telles que Ajax de GwtQuery qui est en réalité juste un wrapper pour XmlHttpRequest, et le RestDispatch de GWTP qui utilise GIN et qui semble être plus adapté pour les applications faisant usage de GWTP.

VII - Résumé

Légende du tableau

Bibliothèque

Popularité

Version actuelle

Avantages

Inconvénients

Request Builder

N / A

N / A

- Fait partie de GWT, et donc pas d'imports additionnels.

- Simple, pas de boilerplate.

Sérialisation/désérialisation des données doit être faite par le développeur, les données sont envoyées/reçues comme chaînes de caractères.

RestyGWT

N / A

2.2.0

- Sérialisation/désérialisation faite par la bibliothèque.

- Fonctionnalités utiles : Dispatchers, JsonP, Handlers…

- Basée sur les Générateurs GWT.

- Problèmes liés au https://github.com/resty-gwt/resty-gwt/issues.

AutoRest

N / A

0.4

- Utilise les annotations processors.

- Utilise RxJava (peut être un désavantage).

- Boilerplate.

- Jeune projet.

- Associée à RXJAva.

Native XmlHttpRequest (JsInterop)

N / A

N / A

- Permet le contrôle sur toute la configuration des requêtes.

- Nécessite des connaissances de l'API JavaScript.

- La Sérialisation/désérialisation des données doit être faite par le développeur.

VIII - Pour conclure…

Les requêtes HTTP sont une fonctionnalité indispensable pour les applications web modernes, et donc le projet GWT doit fournir aux développeurs un mécanisme standard solide et sans effort pour appeler leurs services. Actuellement, les utilisateurs GWT sont dans un dilemme entre les bibliothèques utiles et celles qui représentent un choix viable pour la future version de GWT (3.0). Pour l'instant, la meilleure option qui s'offre aux développeurs GWT est la XmlHttpRequest native avec JsInterop parce que c'est la méthode qui fournit le meilleur contrôle sur les options et la configuration de la requête. Les développeurs GWT peuvent créer leurs propres interfaces réutilisables, et peut-être que des patterns émergeront dans l'avenir. Les autres bibliothèques demeurent des choix pour ceux qui veulent faire avancer les choses rapidement en sacrifiant l'aspect performance. Les contributeurs GWT peuvent peut-être obtenir un peu d'inspiration de projets tels que [gRPC] ( http://www.grpc.io/docs/guides/) pour concevoir la prochaine version du mécanisme RPC pour GWT.

IX - Remerciements

Cet article a été publié avec l'aimable autorisation de Zakaria Amine. L'article original est disponible à cette adresse : GWT HTTP requests alternatives.

Nous tenons à remercier f-leb pour la relecture orthographique attentive de cet article et Mickael Baron pour la mise au gabarit.