HTML5, Spring, NoSQL et mobilité

JugSummerCamp 2012 «HTML5, Spring, NoSQL et mobilité» - 1

HTML5
+
Spring
+
NoSQL
+
Mobilité
Julien Dubois
@juliendubois


Objectif :
réaliser une application Java
moderne, sans (trop) céder à
la mode

Pas de framework inconnu ou
propriétaire
Des technologies standards ou
largement répandues
Pas de langage alternatif que
personne ne comprend
Du code simple et performant
Le XML, ce n’est pas sale


Speaker
• Développeur Java depuis 13 ans
• A commencé avec les EJB 1.0
• Code toujours chez les
clients
• Connait bien Spring Julien Dubois
• Co-auteur de «Spring par Directeur du Conseil et du Développement

la pratique» Ippon Technologies
http://www.ippon.fr
• Ancien directeur de
SpringSource France
• Directeur du pôle
conseil chez Ippon Technologies

Suivez-moi sur Twitter : @juliendubois


Nous allons nous baser sur Tatami, une
application HTML5+Spring+NoSQL+Mobile


Technologies utilisées dans Tatami

• HTML5 :
Twitter Bootstrap, Backbone.JS,
jQuery

• Spring 3.1:
Spring MVC Rest, conﬁguration Java

• NoSQL : Cassandra, Hector, Elastic
Search

• Mobilité : rien :-)


L’ensemble du code
est disponible sur
GitHub
https://github.com/ippontech/tatami

JugSummerCamp 2012 «HTML5, Spring, NoSQL et mobilité» -

Partie I : le HTML5


Que propose HTML5 ?

Attention : cette
conférence est orientée
«entreprise», pas «jeu
vidéo»


1. De nouveaux types de champs (1/2)

1: <input id="emailInput"
2: name="email"
3: type="email"
4: required="required"
5: placeholder="Enter e-mail..."/>
6:
7: <input id="quantityInput"
8: name="quantity"
9: type="number"
10: min="1"
11: max="5" />


1. De nouveaux types de champs (2/2)

• Ces champs sont ensuite
automatiquement validés
par le navigateur
• Sur mobile/tablette, le clavier
correspondant au champ est
activé
• Attention, le support est inégal
en fonction des navigateurs


2. Le SVG

• Permet de faire du dessin vectoriel
• Supporte les événements JavaScript !!!
• Ne fonctionne pas sous IE (utilisation de VML)
• Nombreuses libraires (raphael.js, Google Chart Tools, HighCharts...)


3. CSS 3
een 2D e t en 3D
tions de text
• Tran sforma

• Transitions et animations
• Web Fonts
• Bords arrondis, ombres, opacité ...


4. Les WebSockets
Trop jeune pour être utilisé
concrètement :
• Support inégal des navigateurs,
• Support récent et non
standard des serveurs
d’applications
• Mauvais support des proxys
• Compliqué à débugger
• Contesté au sein même de
l’IETF...


5. Le «storage»
• Web Storage : simples paires clef/valeur,
fonctionne à peu près partout
• Indexed Database : ajoute des
index, ressemble à du
NoSQL
• Web SQL Database : vraie
base de données, non
supportée par Firefox
et IE, en «pause»
au W3C


6. Pour les amateurs de jeux vidéos

• 3D avec WebGL
• Canvas
• Audio et vidéo


Nous devons sauter un trou technologique

• Le HTML5 reste jeune : nombreux bugs et
incompatibilités entre navigateurs
• Coder le HTML/CSS/JavaScript à la main est de
plus en plus compliqué
• 2 à 3 ans pour que HTML5 mûrisse


Quelques outils pour réussir
votre application

• jQuery
• Twitter Bootstrap
• Backbone.js
• Underscore.js
• LESS CSS
• Mustache.js


Twitter Bootstrap

• Framework CSS/JavaScript
• Open Source, développé par
Twitter

• Fourni des grilles de
présentation, des
composants, des plugins
JavaScript

• Permet de faire du
«responsive design»


Backbone.js
• Framework MVC JavaScript
• Open Source, développé par DocumentCloud
• Modèles avec des paires clef/valeur, collections
évoluées
• Se connecte
facilement à un
back-end REST

• Nécessite l’utilisateur d’un
moteur de template pour
rendre les vues (underscore.js)


Partie II : Spring


Fini le MVC et le Struts
«à papa»

Une application = une page HTML
qui fait des appels REST/JSON


Comment coder une
application REST/JSON ?
En Java EE avec l’API JAX-RS
Standard, plusieurs
implémentations : Jersey ou CXF

En Spring MVC REST + Jackson
Simple à intégrer et à
utiliser avec Spring MVC


Pourquoi choisir Spring ?
• Performances : éprouvé depuis longtemps
(singleton), plus rapide que Java EE
• Léger : 15 à 30 Mo de RAM
• Support de nombreuses bases
NoSQL
• Cycle de développement
rapide : Jetty + Hotspot
• Les abstractions et sous-projets :
MVC, cache, sécurité, mobile, social...
• Simple et peu cher à héberger
(8 Euros/mois)


Codons la partie REST...


Exemple 1 : Afﬁchage d’un utilisateur

{
1: app.Model.ProfileModel = Backbone.Model.extend({
2: defaults: {
3: 'firstName': '',
4: 'lastName': ''
JavaScript

5: },
6: url : function(){
7: return '/rest/users/show?screen_name=' + username;
8: }
9: });
10: var profileView = new app.View.ProfileView({
11: model:new app.Model.ProfileModel()
12: });
13: $('#profileContent').html(profileView.render());

{
1: @RequestMapping(value = "/rest/users/show",
2: method = RequestMethod.GET,
3: produces = "application/json")
Java

4: @ResponseBody
5: public User getUser(
6: @RequestParam("screen_name") String username) {
7: return userService.getUserProfileByUsername(username);
8: }


Exemple 2 : Mise à jour du status

{
1: app.Model.StatusUpdateModel = Backbone.Model.extend({
2: url : '/tatami/rest/statuses/update'
3: });
JavaScript

4:
5: var status = new app.Model.StatusUpdateModel();
6:
7: status.set("content", ${"#statusContent"});
8:
9: status.save(null,{
10: success: function(model, response) {
11: app.trigger('refreshTimeline');
12: },
13: });

{
1: @RequestMapping(value = "/rest/statuses/update",
2: method = RequestMethod.POST)
Java

3: public void postStatus(@RequestBody Status status) {
4: statusUpdateService.postStatus(status);
5: }


Quel résultat ?

• Séparation du travail entre le designer et le
développer
• Notre back-end va avoir un très grand
nombre de requêtes REST...

JugSummerCamp 2012 «HTML5, Spring, NoSQL et mobilité» -

Partie III : NoSQL


Comment tenir la charge au
niveau de la couche de
persistance ?


Nouvelle abstraction «cache» de
Spring 3.1
1: @Cacheable("tweet-cache")
2: public Tweet findTweetById(String tweetId) {
3: return em.find(Tweet.class, tweetId);
4: }
5:
6: @CacheEvict(value="tweet-cache",
7: key="#tweet.tweetId")
8: public void removeTweet(Tweet tweet) {
9: tweet.setRemoved(true);
10: em.persist(tweet);
11: }


Le NoSQL avec Cassandra
• Cassandra : une base de données orientée
colonne, très performante en lecture/écriture

• Pas de Single Point of Failure
• Montée en charge «élastique»
sans effort

• Possibilité d’utiliser JPA (avec de grosses limites)
• Mais pas de foreign keys, de transactions ou de
sessions !


Exemple de code Cassandra/Hector
1: public void createUser(User user){
2: em.persist(user);
3: }
4:
5: public Collection<String> getTimeline(String login, int size) {
6: ColumnSlice<String, String> result =
7: createSliceQuery(keyspaceOperator,
8: StringSerializer.get(), StringSerializer.get(),
9: StringSerializer.get())
10: .setColumnFamily(TIMELINE_CF)
11: .setKey(login)
12: .setRange(null, null, true, size)
13: .execute()
14: .get();
15:
16: Collection<String> tweetIds = new ArrayList<String>();
17: for (HColumn<String, String> column :
18: result.getColumns()) {
19:
20: tweetIds.add(column.getValue());
21: }
22: return tweetIds;
23: }


Les problèmes causés par
Cassandra

• Complexe à héberger
• Non consistance des
données
• Pas de transaction
• Retour de la couche
«DAO»


Cassandra + le cache ?

• Combiner les deux solutions
précédentes est-il la solution ultime ?

• Cassandra propose son propre système
de cache interne : très performant et
automatiquement distribué

• Dans certains cas, l’utilisation d’un cache
mémoire local en plus est intéressant :
pas d’accès distant, plus de maîtrise

• Sur Tatami nous avons un gain de
performance d’environ 20%


Le moteur de recherche
• Un des problèmes de
Cassandra : pas de recherche plein texte
(dans la version Open Source)
• Problème récurrent en bases de données
SQL également : les «like» sont très lents
• Deux implémentations de moteur de
recherche dans Tatami
• ElasticSearch (prod «avancée») ou Lucene
(dév ou prod «normale»)
• Simple à mettre en place grâce à Spring
(implémentations différentes du même
service)


ElasticSearch vs Lucene

• ElasticSearch • Lucene
• Basé sur Lucene • Impossible à
• Architecture distribuer
distribuée • Simple à mettre
• Compliqué à en place
héberger


Abstraction «async» de Spring
avec Lucene
1: @Async Insertion dans
2: public void addStatus(Status status) {
3: Document document = new Document(); une thread
4:
5:
document.add(new Field("content",
status.getContent(), séparée
6: Field.Store.NO,
7: Field.Index.ANALYZED));
8:
9: indexWriter.addDocument(document);
10: indexWriter.commit();
11: }

1: @Scheduled(fixedDelay = 10000)
Index mis à jour en
2: public void reloadIndexReader() { «quasi temps réél»
3: searcherManager.maybeRefresh();
4: }


Partie IV : Mobilité


• LA question à se poser : une
application spéciﬁque ou du
«responsive design» ?

• Nous avons fait les deux sur
Tatami...


Pourquoi faire une application
mobile spéciﬁque ?
«Good mobile user experience
requires a different design than
what's needed to satisfy desktop
users. Two designs, two sites, and
cross-linking to make it all work.» --
Jakob Nielsen

http://www.useit.com/
alertbox/mobile-vs-full-
sites.html


Utilisation de Spring Mobile avec
Spring MVC pour choisir quelle vue
renvoyer

Vue «standard»
Requête
HTTP DispatcherServlet
Spring MVC

Vue «mobile»
DeviceResolver
Spring Mobile


Il sufﬁt de faire une vue spécialisée qui
utilise les mêmes services REST
Req
RES uête
Vue T/JS s
ON
«standard»
Spring MVC
REST Cassandra
+
Jackson
Vue
«mobile» uê Ntes
R eq O
ST /JS
RE


jQuery Mobile

• Version de jQuery spéciﬁque
pour smartphones et
tablettes

• HTML5,
cross-platform

• jQuery UI et ThemeRoller


Problèmes rencontrés

• L’application mobile est toujours en
retard fonctionnellement
• Compliqué à tester et à maintenir
• Arrivée des tablettes : il faut faire
une 3ème version ??
• Gestion des thèmes impossible à
gérer entre toutes ces versions


Pourquoi faire du
«responsive design» ?
• Une application unique
• S’adapte «automatiquement» au
support
• Plus de problème de maintenance,
de gestion des thèmes, etc...
• Site «complet» pour
tout le monde


Le résultat
• Etonnamment simple à réaliser avec
Twitter Bootstrap
• Tatami fonctionne sur desktop, mobile
(iPhone, Android, Blackberry, Windows
Phone) ou tablette (iPad, Android)...


Problèmes rencontrés

• Pas de support «natif», par exemple les notiﬁcations
• Quelques contraintes à connaitre
• Fini les «onmouseover»
(ne fonctionnent
pas en mode
«touch»)


En conclusion...
• HTML5 : capacités impressionnantes,
nous ne sommes qu’au début

• Spring 3.1: performance et simplicité
de développement

• NoSQL : ouvre un monde de
possibilités, encore complexe à
utiliser

• Mobilité : application native vs.
responsive design


Merci !
Tatami est hébergé sur :
https://tatami.ippon.fr

Le code source est disponible
sur GitHub :
https://github.com/ippontech/tatami

HTML5, Spring, NoSQL et mobilité

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to HTML5, Spring, NoSQL et mobilité

Similar to HTML5, Spring, NoSQL et mobilité (20)

More from Julien Dubois

More from Julien Dubois (20)

HTML5, Spring, NoSQL et mobilité