Blog Entry: One step back - two steps forward?

If you are watching the Oregami project you may have noticed that it got rather silent during the last months. What could be the reasoning for that? Real life! But exactly due to RL we create everything in the open: data model, ideas, source code. Nothing gets lost, everybody can jump on the Oregami bandwagon at any time to support the first real open game database!

The cause for this blog post is my attention towards the project Spring Boot. Spring Boot was designed "to simplify the bootstrapping and development of a new Spring application. The framework takes an opinionated approach to configuration, freeing developers from the need to define boilerplate configuration" (source). When I switched to Dropwizard with the Oregami server application two years ago, there was no other Java framework with these capabilities: making web development easier with an embedded server. It was exactly what I was looking for, no more "deploying" or "publishing" fat server applications.

In the mean time Spring Boot entered the stage. In April 2014 version 1.0 was released, today the latest release is version 1.3. What if I would try to move the current development state of the Oregami web application to Spring Boot? Before I answer that let me first give you an overview of what we have running so far:

REST-Application with domain objects like "Game", "PublicationFranchise", "GamingEnvironment" and more
HTTP-Calls for GET (read), POST (create) and PUT (update) of these objects
creation and editing of domain objects in the web browser
Cross-Origin Resource Sharing
"Session-per-HTTP-request": one database transaction per HTTP-Request
HSQLDB for development, MySQL for the deployed application
JPA entities with UUIDs as Primary Key
Liquibase for easy database schema updates
Auditing of saved objects with Hibernate Envers
integration tests with rest-assured

Of course all these things would have to be implemented in the refactoring with Spring Boot.

But there is another important question: will we stay with the current architecture which is a REST-Server + a JavaScript Single Page Application?

During the last years there's been a war of architectures going on in my mind: a REST-API is a must, so we developed the Oregami game database as a pure REST application with a web client as JavaScript single page application. That's kind of elegant and makes fun during development. But is it the best choice? I am not the only one who thinks about this:

A few months ago I bought the book "Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement (2nd Edition)" by Aaron Gustafson. The idea of making a website available with basic web technologies at first, enhancing it afterwards step by step and therefore making sure that the website is usable with every web software on the planet, becomes more and more attractive to me. With this in mind I started to refactor my (other) website Kultpower.de. In addition to "Progressive Enhancement" I made use of a technique called "Mobile First": concentrate on devices with small screen (smartphones) primarily and then, using the same code base, enhance for bigger screens. The result so far can be seen at Kultpower.org, and I must say that I am really satisfied with it! (don't forget to try it on your smartphone)

The concept of the so-called "Roca-Style" (Resource Oriented Client Architecture) describes a collection of simple recommendations for decent Web application frontends. I will use these recommendations for a complete refactoring of the Oregami application. I will be able to reuse much of the source code (e.g. for Games, Publications etc.) and make use of the knowledge I gathered with Kultpower.org. Our current JavaScript-Client will be replaced with server side rendered HTML pages created by the template engine Thymeleaf.

So you may have already guessed it: Stay tuned!