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

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).

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.

RequestBuilder request = new RequestBuilder(RequestBuilder.GET, "http://localhost:8085/guest");
                        
    try {
        request.sendRequest(null, new RequestCallback() {
            @Override
            public void onResponseReceived(Request request, Response response) {                            
                GWT.log(response.getText());
                // La réponse est sous la forme d'un String, et donc les données ont besoin de traitements supplémentaires
            }

            @Override
            public void onError(Request request, Throwable exception) {
            }
        });
                                
    } catch (RequestException e) {
        e.printStackTrace();
    }

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 :

public interface GuestService extends RestService {
    
    @Path("http://localhost:8085/guest")
    @GET
    public void get(MethodCallback<List<Guest>> callback);
}

public void onModuleLoad() {
    GuestService service = GWT.create(GuestService.class);

    service.get(new MethodCallback<List<Guest>>() {
        @Override
        public void onFailure(Method method, Throwable exception) {
            GWT.log("Request Failed");
        }

        @Override
        public void onSuccess(Method method, List<Guest> response) {
            response.forEach((g) -> {GWT.log(g.roomNumber);});
        }
    });
}

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.

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.

@AutoRestGwt @Path("guest") interface GuestService2 {
    @GET Observable<Guest> get();
}

static ResourceVisitor osm() { 
    return new RequestResourceBuilder().path("http://localhost:8085/"); 
}

public void onModuleLoad() {
    GuestService2 gs = new GuestService2_RestServiceModel(() -> osm());
    gs.get().subscribe(n -> {
        GWT.log(n.guestId+"");
    });
}

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.

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 :

// Implemented using JsInterop, can also be used from Elemental 2 
private final XMLHttpRequest nativeRequest = new XMLHttpRequest();
    
// false means that the request is synchronous which can not be done in other librairies
nativeRequest.open("GET", "http://localhost:8085/guest", false);

// there are other events such progress, abort, error that are not available in other librairies
nativeRequest.addEventListener("load", new Function() {
    @Override
    public Object call(JavaScriptObject event) {
        GWT.log(nativeRequest.responseText);
        return null;
    }
});

nativeRequest.send();

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.

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.

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.