1. Good by Server...
Welcome Client!
SOFEA - ein leichtgewichtiger Architekturansatz
Sandro Sonntag
Adorsys GmbH & Co. KG
2. Thin Server Architektur
Web API‘s Entwicklung des Webs
REST Inhalt Web-Technologien
Potenziale
Was hat HTML5 Was ist falsch an Rich
mit Architektur zu tun? Server?
Best Practices
3. Über mich
Sandro Sonntag
Java Eetwickler - 10 Jahre Java Erfahrung
in Enterprise Umfeld
Liebe zu Webtechnologien und Webscale Themen
Wie REST, JavaScript/Node.JS, Mongo, Couch,
Appengine
Technical Lead bei Adorsys
Unterwegs als Berater und Softwarearchitekt (CPSA)
https://www.xing.com/profile/Sandro_Sonntag
5. Ursprünge SOFEA
2007 Publikation des Papiers „Live above the Service
Tier“
„How to Build Application Front-ends in a Service-Oriented
World“
durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar
6. Ursprünge SOFEA
2007 Publikation des Papiers „Live above the Service
Tier“
„How to Build Application Front-ends in a Service-Oriented
World“
durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar
Parallel SOUI Publikation - Service Oriented User Interface
„MVC is Dead“ Norlan Wright
7. Ursprünge SOFEA
2007 Publikation des Papiers „Live above the Service
Tier“
„How to Build Application Front-ends in a Service-Oriented
World“
durch Ganesh Prasad, Rajat Taneja, Vikrant Todankar
Parallel SOUI Publikation - Service Oriented User Interface
„MVC is Dead“ Norlan Wright
Andere geläufige Bezeichnung: „Thin Server Architecture“
15. Twitter Saw 600K Signups
Yesterday, It Took More Than 16
Months To Reach Its First 600K
16. Gartner
In the next-generation client/server architecture, the
"client" is a rich application running on an
Internet-connected device, and the "server" is a
set of application services hosted in an increasingly
elastically scalable cloud computing platform.
26. Daten und Repräsentation
sind vermischt
Name Foo
➡Datenstrukturen?
➡Datentypen?
Nachname Bar
Str Laufer-Str 99
Browser Server
27. Daten und Repräsentation
sind vermischt
Name Foo
➡Datenstrukturen?
➡Datentypen?
Nachname Bar
Str Laufer-Str 99
Browser Server
<html>
<body>
<span>Name: Foo</span>
➡Daten und
Repäsentation gemischt
28. Daten und Repräsentation
sind vermischt
Name Foo
➡Datenstrukturen?
➡Datentypen?
Nachname Bar
Str Laufer-Str 99
Browser Server
nd
lo w u scht
o nsf gemi
en tati sch
räs ustau
➡P tena
Da
<html>
<body>
<span>Name: Foo</span>
➡Daten und
Repäsentation gemischt
30. Hohe Latenz
Browser
GET POST POST POST
Seite 1 Seite 2 Seite 3 Seite 4
Usability erfordert eine flüssige Bedienung.
Herkömmliche Webapps reagieren zu langsam auf Benutzer Interaktionen.
33. Komplexität
Präsentationslogik ist am Client und
Server Client Code
Webframework ein Codegenerator für (HTML, JS, CSS)
HTML & JS(denken in 2 Dimensionen -
sehr umständlich)
GUI Events
Generate
State
Webframework
34. Komplexität
Präsentationslogik ist am Client und
Server Client Code
Webframework ein Codegenerator für (HTML, JS, CSS)
HTML & JS(denken in 2 Dimensionen -
sehr umständlich)
GUI Events
Generate
HTML muss erst in Server Templates
verpackt werden
State
Webframework
35. Komplexität
Präsentationslogik ist am Client und
Server Client Code
Webframework ein Codegenerator für (HTML, JS, CSS)
HTML & JS(denken in 2 Dimensionen -
sehr umständlich)
GUI Events
Generate
HTML muss erst in Server Templates
verpackt werden
Debugging in zwei Laufzeitumgebungen
(Client/Server) State
Webframework
36. Komplexität
Präsentationslogik ist am Client und
Server Client Code
Webframework ein Codegenerator für (HTML, JS, CSS)
HTML & JS(denken in 2 Dimensionen -
sehr umständlich)
GUI Events
Generate
HTML muss erst in Server Templates
verpackt werden
Debugging in zwei Laufzeitumgebungen
(Client/Server) State
Der meiste Code dreht sich um das Webframework
Event/Request Handling (Serialisierung,
Protokoll quirx)
37. Komplexität
Präsentationslogik ist am Client und
Server Client Code
Webframework ein Codegenerator für (HTML, JS, CSS)
HTML & JS(denken in 2 Dimensionen -
sehr umständlich)
GUI Events
Generate
HTML muss erst in Server Templates
verpackt werden
Debugging in zwei Laufzeitumgebungen
(Client/Server) State
Der meiste Code dreht sich um das Webframework
Event/Request Handling (Serialisierung,
Protokoll quirx)
Korrektes State Handling unmöglich
40. Fatales Statemanagement
UI State ist am Server
State am Client muss nicht zum Server State passen.
Fehlerbehandlung hierfür ist komplex.
41. Fatales Statemanagement
UI State ist am Server
State am Client muss nicht zum Server State passen.
Fehlerbehandlung hierfür ist komplex.
Client muss immer auf den richtigen Server geroutet werden
42. Fatales Statemanagement
UI State ist am Server
State am Client muss nicht zum Server State passen.
Fehlerbehandlung hierfür ist komplex.
Client muss immer auf den richtigen Server geroutet werden
Skalierung und Failover ein echtes Problem (und sehr teuer)
43. Fatales Statemanagement
UI State ist am Server
State am Client muss nicht zum Server State passen.
Fehlerbehandlung hierfür ist komplex.
Client muss immer auf den richtigen Server geroutet werden
Skalierung und Failover ein echtes Problem (und sehr teuer)
Speicherverbrauch am Server (Beispiel JSF Component Tree)
44. Fatales Statemanagement
UI State ist am Server
State am Client muss nicht zum Server State passen.
Fehlerbehandlung hierfür ist komplex.
Client muss immer auf den richtigen Server geroutet werden
Skalierung und Failover ein echtes Problem (und sehr teuer)
Speicherverbrauch am Server (Beispiel JSF Component Tree)
Server behelfen sich mit Sessiontimeouts (Session bleibt
meist noch 30 Minuten wenn der User bereits weg ist)
48. 6. Fehlende Interoperabilität
HTML Markup ist keine Schnittstelle
... GWT-RPC auch nicht
Echte Services sind sind häufig nicht von „außen“ zugreifbar (z.B. Spring
Services)
... nein, man kann Sie nicht einfach zum Webservice machen!
es ist ein fundamentaler Unterschied ob ein Service als WebService oder
lokaler Service konzeptioniert wurde (Fehlerbehandlung, Call by Value,
Granularität)
Ergo: SOA Projekte müssen von 0 starten
Risiko das Rad neu zu erfinden
49. 6. Fehlende Interoperabilität
HTML Markup ist keine Schnittstelle
... GWT-RPC auch nicht
Echte Services sind sind häufig nicht von „außen“ zugreifbar (z.B. Spring
Services)
... nein, man kann Sie nicht einfach zum Webservice machen!
es ist ein fundamentaler Unterschied ob ein Service als WebService oder
lokaler Service konzeptioniert wurde (Fehlerbehandlung, Call by Value,
Granularität)
Ergo: SOA Projekte müssen von 0 starten
Risiko das Rad neu zu erfinden
Fehlender Fokus auf qualitative Schnittstellen („die sind ja nicht von außen
erreichbar“)
50. 6. Fehlende Interoperabilität
HTML Markup ist keine Schnittstelle
... GWT-RPC auch nicht
Echte Services sind sind häufig nicht von „außen“ zugreifbar (z.B. Spring
Services)
... nein, man kann Sie nicht einfach zum Webservice machen!
es ist ein fundamentaler Unterschied ob ein Service als WebService oder
lokaler Service konzeptioniert wurde (Fehlerbehandlung, Call by Value,
Granularität)
Ergo: SOA Projekte müssen von 0 starten
Risiko das Rad neu zu erfinden
Fehlender Fokus auf qualitative Schnittstellen („die sind ja nicht von außen
erreichbar“)
Präsentation und Geschäftslogik in einem Tier fördert das verschmelzen von
beidem zu einem „Brei“
54. Symptome linderbar,
aber nicht fixbar!
Zustand -> HTTPSession/Conversations
AJAX Feeling -> Partitial Page Rendering
Multi Windows -> Conversations
55. Symptome linderbar,
aber nicht fixbar!
Zustand -> HTTPSession/Conversations
AJAX Feeling -> Partitial Page Rendering
Multi Windows -> Conversations
Browserhistory -> Post/Redirect/Get (PRG)
56. Symptome linderbar,
aber nicht fixbar!
Zustand -> HTTPSession/Conversations
AJAX Feeling -> Partitial Page Rendering
Multi Windows -> Conversations
Browserhistory -> Post/Redirect/Get (PRG)
Failover -> Session Repication = BS! (Speicher, Kosten,
Network Traffic..)
57. Symptome linderbar,
aber nicht fixbar!
Zustand -> HTTPSession/Conversations
AJAX Feeling -> Partitial Page Rendering
Multi Windows -> Conversations
Browserhistory -> Post/Redirect/Get (PRG)
Failover -> Session Repication = BS! (Speicher, Kosten,
Network Traffic..)
58. Symptome linderbar,
aber nicht fixbar!
Zustand -> HTTPSession/Conversations
AJAX Feeling -> Partitial Page Rendering
Multi Windows -> Conversations
Browserhistory -> Post/Redirect/Get (PRG)
Failover -> Session Repication = BS! (Speicher, Kosten,
Network Traffic..)
Verhindert echtes Webscale!
59. Hmm, Code am Server war
doch immer eine gute Idee
JS sucks! Bowser Inkompatibilität! ...und die
Sicherheit!
60. Ja, bis 2005 war das richtig
Für viele hat sich die Welt seither nicht weiter gedreht
Seit 2005 gibt es viel neues
AJAX
Browser Events
CSS 2/3
JavaScript Programming Patterns (Classes,Events, DOM)
jQuery
DOM Positioning / Box Models
62. Motivation SOFEA
Präsentation an den Client (seperation of concerns)
Services zum Server
SOA - Agnostische WebServices
Multi Device (Mobile, Portal, Webclient, Richclient,
APIs)
Webscale
64. Application Download
Webserver
Application Network
Application- Business Logic
Container
65. Presentation Flow
Webserver
Application Network
Application- Business Logic
Container
66. Data Interchange
Webserver
Application Network
Application- Business Logic
Container
67. Back to basic
richtiges 3 Tier
Client
HTML Renderer
Model
Controller View
Business Logic
Server
68. Back to basic
richtiges 3 Tier
Client Client
Präsentation
HTML Renderer
Controller View
Model
Model API
Controller View
Business Logic Business Logic
Server Server
69. Back to basic
richtiges 3 Tier
Client Client
Präsentation
HTML Renderer
Controller View
Model
Model API
Controller View
Business Logic Business Logic
Server Server
70. Back to basic
richtiges 3 Tier
Client Client
Präsentation
HTML Renderer
Controller View
Model
Model API
Controller View
Business Logic Business Logic
Server Server
74. SOFEA (Rich) Clients
Nicht RESTful
SOFEA verletzt das REST Prinzip HATEOAS (Hypermedia as the
Engine of Application State)
State ist nicht Bestandteil der URL
idR. ein großer Download
History und „Browser Back“ problematisch
# URI Fragmente können helfen
neu: Browser History API
Aber: Offline fähig
80. Kompromiss:
Rich Thin Clients
RESTful
viele kleine Downloads
reduzierte Komplexität
Aber:
nicht offline fähig
nicht als Mobile App geeignet
Server Roundtripps bei Wechsel der URL/Resource
83. Vorteile SOFEA
Trennung zwischen Präsentation und Geschäftslogik
Aufgeräumtes Programmiermodell (GUI läuft am Client)
Keine Serverlatenz bei GUI Operationen
84. Vorteile SOFEA
Trennung zwischen Präsentation und Geschäftslogik
Aufgeräumtes Programmiermodell (GUI läuft am Client)
Keine Serverlatenz bei GUI Operationen
Hoch skalierbar
Client side state management
85. Vorteile SOFEA
Trennung zwischen Präsentation und Geschäftslogik
Aufgeräumtes Programmiermodell (GUI läuft am Client)
Keine Serverlatenz bei GUI Operationen
Hoch skalierbar
Client side state management
Offlineanwendungen
86. Vorteile SOFEA
Trennung zwischen Präsentation und Geschäftslogik
Aufgeräumtes Programmiermodell (GUI läuft am Client)
Keine Serverlatenz bei GUI Operationen
Hoch skalierbar
Client side state management
Offlineanwendungen
Mobile Apps
87. Vorteile SOFEA
Trennung zwischen Präsentation und Geschäftslogik
Aufgeräumtes Programmiermodell (GUI läuft am Client)
Keine Serverlatenz bei GUI Operationen
Hoch skalierbar
Client side state management
Offlineanwendungen
Mobile Apps
Interoperability
SOFEA fördert „echte“ und qualitative Services
Backend kann in jeder Spache geschrieben sein (Ruby, JS, Java, .net...)
96. MVP (Model View Presenter)
Pattern
View
View Model
Presenter
Controller
Model
97. SOFEA Architecture 2.0
MVP + EventBus
Menü Mail Chat
View View View
Presenter Presenter Presenter
Event Bus
Application Controller
Network
Service
98. OpenAJAX Hub
Standard Client Side JavaScript Hub
publish/subscribe
zum schreiben von Secure Mashups
Sandboxing von Mashups
aktuell in Version 2
OpenAjax.hub.publish("de.adorsys.urlaubsantrag.new", "2007.08.05");
OpenAjax.hub.subscribe("de.adorsys.urlaubsantrag.*", function() {
//hello
}, this);
100. SOFEA Architecture 2.0
Push
Event Bus
Application Controller Repository
Technologie
Poll Network
AjaxPush/Comet
Long Poll Service
Websockets/Webworker
101. SOFEA Architecture 2.0
Offline Cache
Mail
Event Bus
Application Controller Repository Online Repository Offline
Network
Offline Apps Lokal
Storage
Performance durch
Cache Service
103. Scaling SOFEA
Client Client
GUI Rendering am Client
Konzept: Stateless Backend
REST Server Server
Caching (Client/Server)
einfache und „billige“ Skalierung durch zusätzliche
Hardware
keine (sticky) Sessions
transparent Failover
104. Scaling SOFEA
Client Client
GUI Rendering am Client
Konzept: Stateless Backend
REST Server Server
Caching (Client/Server)
einfache und „billige“ Skalierung durch zusätzliche
Hardware
keine (sticky) Sessions
transparent Failover
105. Scaling SOFEA ein neues Problem die Datenbank?
Client Client
GUI Rendering am Client
Konzept: Stateless Backend
REST Server Server
Caching (Client/Server)
einfache und „billige“ Skalierung durch zusätzliche
Hardware
keine (sticky) Sessions
transparent Failover
106. Caching
Repository Online
RESTful HTTP ist der Schlüssel Network
HTTP Client Cache (expires, E-TAG)
SQID
durch Infrastruktur (Reverse Proxy Cache)
Serverside Service Cache
Service
108. Authentication in SOFEA
Die meisten Appserver präferieren Session Auth
Dadurch ist Server stickiness erforderlich
109. Authentication in SOFEA
Die meisten Appserver präferieren Session Auth
Dadurch ist Server stickiness erforderlich
Lösung: Security Tokens
Token basierte Protokolle
Eigene Protokolle
OAuth
OpenID
111. Funktionsweise - OAuth
1. erzeuge Request Token Token
Service Client Server
(IdP)
Service
Provider
112. Funktionsweise - OAuth
2.
Au
th
en
tis
ier
er
eq
ues
tT
ok
en
1. erzeuge Request Token Token
Service Client Server
(IdP)
Service
Provider
113. Funktionsweise - OAuth
2.
Au
th
en
tis
ier
er
eq
ues
3. redirect request Token
tT
param
ok
en
1. erzeuge Request Token Token
Service Client Server
(IdP)
Service
Provider
114. Funktionsweise - OAuth
2.
Au
th
en
tis
ier
er
eq
ues
3. redirect request Token
tT
param
ok
en
1. erzeuge Request Token Token
Service Client Server
4. erzeuge Access Token (IdP)
Service
Provider
115. Funktionsweise - OAuth
2.
Au
th
en
tis
ier
er
eq
ues
3. redirect request Token
tT
param
ok
en
1. erzeuge Request Token Token
Service Client Server
4. erzeuge Access Token (IdP)
5. A
PI C
all Service
Provider
116. Funktionsweise - OAuth
2.
Au
th
en
tis
ier
er
eq
ues
3. redirect request Token
tT
param
ok
en
1. erzeuge Request Token Token
Service Client Server
6. check Token
4. erzeuge Access Token (IdP)
5. A
PI C
all Service
Provider
119. OpenSocial Gadget
Opensocial Server Gadget Server
Open Social
Container get Gadget XML
load Gadget Gadget App Server
Open Social Server
Social Graph
data request REST Request
Gadget
Application REST API
Open Social REST
API
120. Write Gadgets
Google Docs
Gmail - Kontext bezogene sidebar gadgets.
Calendar - Gadgets für die Calendar sidebar.
iGoogle - Gadgets für das Google „Portal“.
121. SOFEA für Mobile Apps
Native Clients
Betriebssystemabhängig (Kosten, Skills)
Mobile Websites (optimierte Websites für Mobile)
Hybrid Mobile Apps
122. Single Source - Hybrid Apps
Phonegap/Corona
Hybird HTML5
App
124. Webhooks
Das Problem...
My Service Other Service
Other Service
Other Service
Other Service
Other Service
Other Service
Other Service
Poll ist ineffizient poll poll
poll
hohe Latenz poll
Payment Service
125. Webhooks - Die Lösung
My Application
3. push
1. register
My Service
Payment Service 2. push
Other Service
126. Webhooks - Die Lösung
Anwendungsgebiete
My Application
Events Notification
Data Pipelining 3. push
1. register
Plugins
My Service
Payment Service 2. push
Other Service
127. Web Intends
Bild auswählen
My Application
Bild aus Flicker übernehmen
128. Code Beispiel
Web Intends
Registrieren
<intent
action="http://webintents.org/share"
type="image/*"
href="share.html"
/>
Feuern:
var intent = new Intent("http://webintents.org/share",
"text/uri-list",
"http://news.bbc.co.uk");
window.navigator.startActivity(intent);
Thema was mir am herzen liegt\nkeine Code Beispiele daf&#xFC;r bilder:)\nParadigmenwechsel: Fat Clients -> Thin Clients -> Richclients\nPerspektive etwas zu &#xE4;ndern\n\nREST Architekturstiel des Internets (REST Vortrag)\nWas tuen wir uns gerade an mit Server Side Webframework\nWas macht die Thin Server Architecture besser?\n
Sandro Sonntag \nFirma Adorsys\nJEE Java und Webtechnologie Umfeld, Mobile\n700m von hier B2\nSpiele gerne mal mit neuen Technologien herum. Mittlerweile vermehrt mit Webtechnologien\nJavascript (Hass/Liebe)\nTellerrand\nLarge Scale Architekturen von eBay, Amazon, Twitter und Co\nNoSql DBs\n\n\n
\n
Thema ist nicht all zu neu\n\nFokus damals auf Services f&#xFC;r mich ist der Fokus ehr\n
Thema ist nicht all zu neu\n\nFokus damals auf Services f&#xFC;r mich ist der Fokus ehr\n
Thema ist nicht all zu neu\n\nFokus damals auf Services f&#xFC;r mich ist der Fokus ehr\n
\n
\n
3,5 Jahre f&#xFC;r die ersten 1000\n
RDF spielt offensichtlich keine Rolle :(\n
sind Browser die Systeme\n
Salesforce 50 % des Traffics durch APIs\n
SIPGate API bei Adorsys\n
\n
Client-Cloud Applications: The Rebirth of Client/Server Architecture \nEric Knipp, David Mitchell Smith, David W. Cearley, William Clark \n&#xA0; \nSoftware engineering best practices have rebalanced over the years among monolithic, modular, and object- and service-oriented. A classic "centralization versus decentralization" battle has played out repeatedly as the pendulum swung from "big iron" to "big client" and back again. This dynamic, alongside the emergence of cloud computing and the proliferation of powerful new computing devices, is leading to the client-cloud application style, which borrows from and improves client/server architecture. \n&#xA0; \nKey Findings \n&#xB7; &#xA0; &#xA0; In the next-generation client/server architecture, the "client" is a rich application running on an Internet-connected device, and the "server" is a set of application services hosted in an increasingly elastically scalable cloud computing platform. \n&#xB7; &#xA0; &#xA0; Applications consume increasing amounts of server-side computing and storage capacity to satisfy the increasingly complex demands of Web users, but the shift toward usage-metered cloud services, increased demand on networks, robust capabilities of handheld devices and the need to manage bandwidth use on these devices create incentives to minimize the Web application computing and storage footprint, and exploit the intelligence and storage of the client device. \n&#xB7; &#xA0; &#xA0; Internet-connected machines continue to decline in cost while growing more powerful, and a growing set of rich application containers offers an opportunity to tap into this power, potentially offloading work from costly servers to user-financed client devices. \n&#xB7; &#xA0; &#xA0; Unlike the earlier client/server era, in the cloud-client era, the application elements and data on the client device will generally be installed, managed and mirrored from the cloud services platform through an app store or marketplaces, reducing the complexity and cost of managing the client environment. \n
\n
\n
Alle Rechte vorbehalten von samsungtomorrow\n
\n
Stichwort Serviceprovider\nStichwort Mashups\n\n
Frage: Wer hat Spa&#xDF; mit dem Programmiermodel heutiger Mainstream Webframeworks?\n Alle Rechte vorbehalten von Johannes Jansson\n
Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
Gezwungenermassen wandert logik von Server zum Client oder ist gar redundant (Validierung)\nFancy Anforderungen von Marketingabteilung f&#xFC;hren h&#xE4;ufig zu logik auf Client und Server (jQuery)\nergo Webdeveloper muss Webframework + JS Libs beherschen\n\nBeispiel von Druck-Popup\nServerside Frameworks m&#xFC;ssen mit AJAX APIs zusammenarbeiten\nUnzureichender Einfluss auf generierten Clientcode\n\nStatesyncronisation wird zunehmend zum Problem\n\n
Beispiel Browser back\nBeispiel Multi window\n
Beispiel Browser back\nBeispiel Multi window\n
Beispiel Browser back\nBeispiel Multi window\n
Beispiel Browser back\nBeispiel Multi window\n
Beispiel Browser back\nBeispiel Multi window\n
Beispiel Browser back\nBeispiel Multi window\n
\n
Die Geschichte von SEAM und Co. Entity Manager bla\n
Die Geschichte von SEAM und Co. Entity Manager bla\n
Die Geschichte von SEAM und Co. Entity Manager bla\n
Die Geschichte von SEAM und Co. Entity Manager bla\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Beispiel WebGL\n
Achtung es gibt noch eine Folie zu den Vorteilen\n