CODEWITHSUNDEEP
gwt
Vic
Vic

Reputation: 1888

GWT non-Java backend application structure

Does anyone know where is a good example of GWT application with non-Java backend? Something like the "Contacts" application on the official pages of GWT. I'm interested in the following topics specifically (this is how I see the "back" part of the application, but it may be different, of course):

I know, there are many similar topics here, but I haven't found one, which is focused on the structure of the client part.

Upvotes: 0

Views: 387

Answers (1)

Blessed Geek
Blessed Geek

Reputation: 21674

Use REST on both sides. PHP/Python REST server-side. GWT client-side.

Don't use GWT-RPC.

The following gives a guideline for Java-java REST, but there is leeway to move out of server-side Java. It explains why REST is appropriate.

http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.

REST is an industry established pattern (Google. Yahoo, in fact every stable-minded establishment deploys REST services).

REST is abstracted as a HTTP level data structure. Which Java, PHP and Python have established libraries to comply to ensure DTO integrity.

Communication layer (the very back one). Should it use generics ???

Don't understand the question or why the question exists. Just use the REST pattern to provide integrity to non-homogeneous language between server and client and to HTTP request/response.

If you are using Java at back-end, there is no escape from using generics. Generics saves code. But using generics extensively needs programmer to have equally extensive visual capacity to visualise the generics. If your back-end is on PHP or Python, are there generics for PHP? Python generics? Might as well stay in Java land or C# land and forget about Java-free service provider.

Did you mean DTO polymorphism? Don't try polymorphism or decide on it until after you have established your service. Then adaptively and with agility introduce polymorphism into your DTOs if you really see the need. But try to avoid it because with JSON data interchange, it gets rather confusing between server and client. Especially if they don't speak the same programming language.

If you are asking HTTP level generics? I don't know of any framework, not SOAP, not REST where you could have generics carried by the XML or JSON. Is there? Generics?

Service layer? REST.

Requests caching? Cache at every appropriate opportunity. Have service-provider cache query results for items common and static to all sessions like menu, menu/drop-down box choices, labels, etc. Cache your history and places.

On GWT side cache records so that forward/backward button will not trigger inadvertent query. Use MVP pattern and history to manage history traversal that might trigger redisplay of info.

If you are talking about unified info abstraction, you should start your project with JAX-RS to define/test the API and perform data abstraction. Without performing any business logic.

Then, once your HTTP-level APIs andDTOs are defined, convert server-side to using language of your choice to proceed to write more complex code.

BTW, I don't dig your terminology "Backend".

We normally use the terminology client-side for service consumer, server-side for service provider, backend for data repository/persistence access, mid-tier or middle-ware for intervening/auxiliary software required to provide mathematical/scientific/graphical analysis/synthesis.

If our terminologies did not coincide, I probably answered this question wrong.

Upvotes: 1

Related Questions