GWT architecture best practices and lessons learned

p.g.taboada | pgt technology scouting GmbH
Google Web Toolkit
Architecture
Best Practices
Donnerstag, 25. April 13

http://gwtreferencelist.appspot.com

‣GWT Development
‣Basics
‣Structuring the UI
‣Communication
‣Scaling

Shift
happened
Java development,
JS deployment,
Async,
RPC,
RIA/ single page,
...

TextBox t = new TextBox();
RootPanel.get().add(t);

Browser Server
user action
full html response
full html response
full html response
user action
user action

Browser Server
event
first request
full html response
data
data request
data
data request
event
event
event

low level, generic toolkit

let‘s build big things

TextBox t0 = new TextBox();
VerticalPanel...
SplitPanel...
ScrollPanel
RootPanel.get().add(mainPanel);

Run, Forrest. Run!

Hoppla

framework wizardry needed

BE CAREFUL. GWT DEVELOPMENT
IS COMPLICATED HOT NEW STUFF.

WELL, IT‘S NOT NEW...

Jan 2000 Jan 2005
XHTML 1.0
Jan 2000
HTML 4.0.1
Dez 1999
CSS 2
Mai 1998
HTML 4.0 update
April 1998
XHTML 1.1
Mai 2001
HTML 2.0
November 1995
HTML 4.0
Dezember 1997
Java EE 1.2
Dez 1999
JDK 1.1
Feb 1997
Internet Explorer 6
Aug 2001
JDK 1.0
Jan 1996
CSS 2.1
Feb 2004 – Jun 2011
CSS level 2 revision 1, often referred t
errors in CSS 2, removes poorly suppo
interoperable features and adds alread
browser extensions to the specification
with the W3C Process for standardizi
specifications, CSS 2.1 went back and
Working Draft status and Candidate R
status for many years.
J2SE 1.2
Dez 1998
J2SE 1.3
Mai 2000
CSS 1
Dez 1996
HTML 3.2
Januar 1997

nothing new here

nothing new here too
Jan 2007

how can I avoid this?

don‘t public instance the singletons

event bus please
http://jarrettws.blogspot.de/2010/05/public-transport.html

eventbus.fireEvent(
NotificationEvent.info(
"Daten wurden erfolgreich gespeichert"
)
);

USE MVP!
You will get
used to it

presenter
model
clientFactory
eventBus
panel
view

presenter
view interface
presenter interface
model
desktop view
tablet view mock view

public interface LoginView extends View {
void setPresenter(LoginView.Presenter currentPresenter);
void presetEmailFieldWith(String email);
void doShowApplicationMetadata(AppData params);
public interface Presenter extends LemniscusPresenter {
void userLoginWith(String username, String password);
void userDidAskForRegistrationPlace();
void userWantsToChangePassword(
int verificationCode, String userEmail, String
newPasswordToUse);
void userRequestedVerificationCodeForPasswordChange(String email);
}
}

void setPresenter(LoginView.Presenter currentP
void doShowApplicationMetadata(AppData params)
public interface Presenter extends LemniscusPr
void userLoginWith(String username, String
int verificationCode, String userEmail,
MyDesktopViewImpl extends Composite implements LoginView

void setPresenter(LoginView.Presenter currentPresenter)
void doShowApplicationMetadata(AppData params);
public interface Presenter extends LemniscusPresenter {
void userLoginWith(String username, String password
int verificationCode, String userEmail, String ne
void userRequestedVerificationCodeForPasswordChange
}
}
MyLoginPresenter extends AA... implements LoginView.Presenter

BUT ON IE 6 IT IS SO SLOW!

too many widgets ain‘t good

CREATE CUSTOM WIDGETS
don‘t extend FlextTable
don‘t extendVerticalPanel
don‘t extend SimplePanel
CREATE CUSTOM EVENTS

if you can, do it in CSS
@-webkit-keyframes redPulse
{
from
{
box-shadow: 0px 0px 2px #ff0033;
}
50%
{
}
to
{
}
}

use CSS layout
<g:LayoutPanel styleName="{B.style.mainContent}">
<g:layer left="0" right="340px" top="0" height="50%">
<g:SimpleLayoutPanel styleName="{B.style.mainWidget}" addStyleNa
<ux:DashboardTermineDataGrid ui:field="terminetable" styleName
</g:SimpleLayoutPanel>
</g:layer>
<g:layer right="0" width="340px" top="0" height="50%">
<ux:KWStatsDataGrid ui:field="statstable" styleName="{B.style.
</g:layer>
<g:layer right="0" left="0" bottom="0" height="50%">
<ux:WartelisteDataGrid ui:field="wartelistetable" styleName="{
</g:layer>
</g:LayoutPanel>

Ray Ryan - lessons learned

„just do it“ pattern
„View A“
„View B“
mainPanel.setWiget(
aWidget );
mainPanel.setWiget(
bWidget );
some action

hard to maintain

history
management
from day one!
back button and
refresh as a
feature (not a
catastrophe)

keep it
stupid
simple
• use PLACES framework
for main level navigation
• if you really need to, nest
activities for a second
level. try not to.
• use dialogs for user input,
showing data. dialogs are
easily reused.

Once upon a time, a
good designer does
good a good looking
design...
‣ he will be using photoshop
or dreamweaver
‣ he will not use the
software
‣ he will not build the
software
‣ he will not maintain the
software

top menue bound to places framework

switching between places with fade in and out

teach user to wait until application is ready again

gives us enough time to load the required content
300ms out 500ms in

Komponents
inside an
„activity“ fire
non public,
custom events

datepicker
sends KW
selected event

presenter may
goto itself, view
may be cached

STATELESS
VIEW
URL contains
EVERYTHING
needed to
rebuild view
user hits
reload
GWT apps
starts, activity
gets fired
presenter
loads data
from server
view is back
again

some actions don‘t require PLACE navigation at all

use POPUPS to stay ABOVE navigation

let POPUPS/
DIALOGS move
slowly into view
pin POPUPS to
one side of the
window

Don‘t move your
user away from his
„PLACE“ unless
you have to.
Search DIALOG
slides in from right
side, stays on TOP

Navigation must not hurt
• The application shown uses only 3 levels of
navigation, DOES NOT NEED MORE
• PLACES used for bookmarkable entry points/
back button navigation consistency
• Activities should be STATELESS, to survive page
reloads
• Learn from OTHERS

BEFOREYOU ADD THE
LOGO TO THE TOP
HOW MANY PIXELS DO
YOUR USERS HAVE? the designer or
marketing guy
using photoshop is
probably sitting in
front of a 27“
apple cinema
display

Honor the A in AJAX
‣ Javascript does not block
Get over it
‣ Latency is not a myth
‣ Results must not arrive in the call
order

MARSHALLING / UNMARSHALLING
IN JAVASCRIPT IS SLOW

BUILDING A GENERIC FRAMEWORK FOR
MARSHALLING/ UNSMARSHALLING DATA SUCKS

DON‘T BINDYOU NEXT 3YEARS OF WORK
AGAINST SOME COMMUNICATION PROTOCOLL

LOADING TOO MUCH DATA WILL ALWAYS HURT

GWT-RPC
is a good
solution if
handled
with care
SomeResult someMethodName(SomeParameter spo)
GWT-RPC
binds many
methods
into one
interface
Interface
Versioning
is a
monstrous
thing

SomeResult someMethodName(SomeParameter spo)
the method names bind the requests to the result
typesafety all the way

USING GENERICS FOR TYPESAFETY, GET RID OF
METHODS AND INTERFACES

<A extends Action<R>, R extends Result> R execute(A action);
now we just one interface with one method
typesafety all the way

command
pattern
GOF Pattern
commonly used in
Rich Clients

someAction
someResult
someActionHandler

someAction
someResult
someActionHandler
POJOS

someAction
someResult
someActionHandler
multiple
versions
someActionV2
someActionHandlerV2

someAction
someResult
someActionHandler
multiple
versions
someActionV2
someActionHandlerV2
someResultV2

someAction
someResult
someActionHandler
GWT-RPC
client server
batching
caching
security
caching
exception translation
security
GWT client

someAction
someResult
someActionHandler
RMI / HTTPInvoker
client server
batching
caching
security
caching
security
Java client

someAction
someResult
someActionHandler
JSON-servlet
client server
batching
caching
security
caching
security
Mobile client

batchAction
someAction1
batchActionHandler
someAction2
someAction3
batchResult
someResult1
someResult2
someResult3
client server
batching can
be manual or
automatic
server executes
actions in given order

BATCH EXECUTION ALLOWS FOR FINE GRAINED
COMMANDS AND REUSE

toggleTerminMetadata
reloadDashboardTermine
BooleanResult
DataListResult<Termin>

reloadTermin
BooleanResult
DataResult<Termin>

loadMonthStats
BooleanResult
DataResult<MonthStats>
loadMonthTermine DataListResult<Termin>

• Every client brings his own CPU power
• The client does the page rendering
• GWT provides different ways to reduce number
of requests even more
• The server must „only“ authenticate the user
and provide the data, perform the actions
requested by the client
GWT scaling is easy...

WHAT CAN POSSIBLY GO WRONG?

LETS TALK HIGH TRAFFIC...
HIGH TRAFFIC IS WHEN ONE SERVER IS NOT ENOUGH

• Bandwith issues
• Connection pool bottlenecks
• Thread pool bottlenecks
• CPU bottlenecks caused by reflection API calls
• High JVM garbage collection CPU usage
HIGH TRAFFIC
PROBLEMS

NOT REALLY GWT PROBLEMS,
BUT WHAT CAN WE DO?

TX TX
TX TX
TX
TX TX
TX
TX
avoid „tx
collisions“

TX TX TX TX
TX
TX
TX
TX TX
TX
TX
TX
TX
TX
TX
load small
portions of
data, do it
often

IMPLEMENT REAL LOAD BALANCING
EACH REQUEST GOES TO THE NEXT AVAILABLE SERVER

• Don‘t stick a session to a server.
Why send a user over and over again to a
possible overloaded server?
• Don‘t store anything on the HTTP session. Let
the load balancer balance the load.
• Session replication is expensive and does not
scale well
SCALING HOW-TO

Webserver
Webserver
LB Webserver
Webserver
Webserver
Session Cache
STATELESS WEB
Webserver

Session Cache
Session state should not change,
just expire
Session state could contain user
id, client id, session id, user roles
If session cache becomes
bottleneck, use distributed
cache, eg. memcached
Session Cache
Session Cache

Thanks!

GWT architecture best practices and lessons learned

Recommended

Recommended

More Related Content

Similar to GWT architecture best practices and lessons learned

Similar to GWT architecture best practices and lessons learned (20)

Recently uploaded

Recently uploaded (20)

GWT architecture best practices and lessons learned