writing html5 apps with google app engine, google closure library and clojure
DESCRIPTION
This is the talk I gave at the Google Developer Day 2010 in Munich. The room was crowded. All seats were taken. People were sitting in front of the "stage" and still lots of people were standing in the back. So there was lots of interests in Clojure Programming on Google App Engine. Thanks Google for having us here! :)TRANSCRIPT
Revised v4Presenter
Writing HTML5 apps with Google App Engine, Google Closure Library and Clojure
Stefan Richter, Founder & CTO of freiheit.com
How many people are here in this talk because of:- Google AppEngine- Google Closure Library- Clojure
So let‘s talk a bit now about why I think it is more difficult to build a client-side component-based HTML5 app in comparison to rendering complete HTML pages on the server.
„I believe that the more you know about the past, the better you are prepared for the future.“ -Theodore Roosevelt
Before the first internet boom, people built desktop apps often like this:Just put some widgets into a window, fill out the event handlers and „bam“, there you have a maintenance hell.
Buildingcomplex
event chains
The widgets/components send events between each other. They catch events, execute some code which maybe fires even more events.
In 2-Tier Client-Server apps, people were even accessing the database directly from the event handlers.
SQL Rows
The IDE industry was built completely around this programming model. Just take some components and wire them together by using events. They dreamed about „software factories“ and „component markets“.
But it was not that easy.Code like this is very difficult to maintain and understand:Soon you‘ll end up with very complex event chains, which are maybe not understood anymore just by reading the code.
So my very first rule is:
„You should be able to understand what your application does just by reading the code.“
Maybe you are surprised now, because this seems so obvious.
But: JavaScript makes it very easy for us to write Callback-Functions. So it is very easy to take this approach too far!
With Server-based HTML apps, you are rendering the complete page in one piece. One request and one response at the time. In this moment, you don‘t have to think much about different threads of execution.
One side-note about GWT:
GWT makes GUI programming inside the browser much easier, but it doesn‘t take the burden away from you to structure your application in the right way.
For the HTML5 client of TheDeadline, we first thought about the User-Experience (UX), then how we wanted to generate the User-Interface (UI) and then how the UI should communicate with the underlying backend services.
1. User Experience
In a browser, with CSS3 and JavaScript, you can build much richer user interactions than with the classical WIMP approach.
So why use a traditional Widget set instead of building a custom-made user-interaction?
Here comes my second rule:
„Don‘t try to write Windows-style Desktop apps inside the browser.“
2. User Interface
With HTML5, you will have to generate more and more of the HTML code on the client-side. One way to do it is to use a client-side template system. We took Google Closure Templates, because you can use them on the server, too!
Here comes my third rule:
„Be prepared to render most of your HTML code on the client-side.“
We try to do as much page-rendering on the client-side as we can, only encapsulating state into custom-widgets when needed.And we try to centralize the event-handling as much as possible with our event-db.
3. Accessing backend services
Google App Engine
Browser
event-db API
XHR/JSON Notification
Datastore
TheDeadline HTML5 UI (rendering)
NotificationData-Access(Key/Value Pairs)
HTML5: Local Storage API
User-Events
From the Google Datastore to the JavaScript User-Interface: We are using Key/Value Pairs as the primary datastructure in TheDeadline.
I think, that this is the future of application development.
No more „impedance mismatch“.No more Object-Relational mappers.
No more transformation steps between different incompatible „formats“ like database rows, XML, (serialized) objects
Do we really need classes/objects to pass data around?There are many flavors of the object-oriented paradigm. Compare Smalltalk, CLOS or JavaScript to Java. Or see how Clojure brings the advantages of OOP to a non-OOP programming language with protocols.
Let‘s see how we are doing this in TheDeadline.
We generate the datastore access code on the server with Clojure Macros.
With the macro-generated functions, we can create new todos.
Clojure works internally with Key/Value pairs. We can store and retrieve them seamlessly to and from the Google Datastore. And we can send them to the client as JSON.
The next slide is from my keynote today. It shows the way we write functional code on both the client- and the server-side. We are using exactly the same data-structures in two different languages.
Simple fictitious example:
{todo: „@[email protected] please check the #homepage“}
This might be transformed by a function into this before saving:
{todo: „@[email protected] please check the #homepage“, tags: [„homepage“], responsible-id: 4711, owner-id: 1337}
In your programs, you are transforming, folding and passing around data all the time. If your programming language can handle this syntactically, you might not need classes most of the time.
This brings us to my fourth rule:
„Don‘t write JavaScript code in the style of the Java language. Forget everything you learned by writing Java code.“
So no complex class hierarchies. JavaScript wasn‘t made for this.
Try out how far you can go with just key/value pairs and write functional JavaScript code without side-effects to operate on this data.
By the way: This is much easier to test, too!
Our event-db has some more advantages: You can write apps that the user can run offline. You‘ll need this for mobile HTML5 apps.
This is why my fifth rule says:
„Plan ahead for Offline capabilities. But be aware, that users maybe try to sync stale data.“
Therefore my sixth rule:
„You‘ll need an idea how to cope with concurrent modifications, when it is likely that your users can modify the same data at the same time and this could cause problems.“
We are versioning all changes. But we don‘t store the version data. We store the operations that changed the data.
Nice side-effect: Perfect real-time statistics about the usage of your system.
I think we are coming to the end of my talk.
Even if you don‘t share my opinions, maybe it made you think. My ideas are evolving, and changing, too. Interested?Follow me on Twitter: @smartrevolution
Some more rules:
7. You need push notifications.8. Key/Values != ER-Model9. Log client-side exceptions to the server.
10. Have fun! Build your dreams!
App Engine Clojure TheDeadline
+ =
TheDeadline:http://www.the-deadline.com
Corporate Blog:http://www.hackers-with-attitude.com
Corporate WebSite:http://www.freiheit.com