Showing posts with label Development. Show all posts
Showing posts with label Development. Show all posts

Saturday, November 26, 2016

Domain Driven Design, CQRS, Event Sourcing, Hexagonal Architecture & more


The road to the right software architecture can be very long. Especially when you're not a professional software architect who helps his customers with developing complex applications day by day.

What will be the Oregami way to the right software architecture? If you've been monitoring our project from the beginning, you know that we threw over the chosen technologies one ore two times already. In the beginning I only had the classical multi-tier architecture in mind and mainly thought about which Java framework to use for persisting our game objects and which database software to use for that. Until today my mind changed in many ways.

Saturday, July 9, 2016

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! (smile) 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! (big grin)

Wednesday, June 11, 2014

Open source RESTful server application (Dropwizard - Google Guice - JPA Hibernate)

Around one year ago I decided to use the Java framework Dropwizard for our server application. Since then I read a lot, I learned a lot and I implemented many things.

As the recently published new Dropwizard version required some re engineering of our application, I used the opportunity to start all over again from the beginning to strengthen my knowledge about the whole implementation. I want to permanently understand every single detail of it, that's the only way I can extend and document it in a meaningful way. It should also help other people to get involved in the development!

In order to be able to provide my technical progress to the outside world in a useful way, I created a complete new ToDo application which is generic, thus stripped of the whole Oregami context. You know the drill with those to-do's: an incomplete thing with a list of features (name, description, state, ...) that still need doing.

Today the generic application contains the following stuff:
  • RESTful app based on Dropwizard version 0.7.0
  • Dependency Injection with Google Guice
  • Hibernate / JPA 2.1 as persistence framework
  • HSQLDB as (in memory) database
  • "Transaction-per-HTTP-request" with Guice PersistentFilter
  • Support for cross-origin resource sharing
  • JPA entities with UUIDs as key
  • a pattern for accessing and manipulating entities with HTTP REST calls
    (Resource => Service => DAO => entity)
  • a pattern for ServiceResult objects which contain ServiceErrorMessages (which can later be bound to the corresponding web form fields in the client)
  • continuous JUnit tests to assure correct functionality
In the near future the following aspects should be added:
  • authentification
  • Hypermedia with HATEOAS
  • more complex entities (1-to-n-relations)
The complete source code is available for everybody at Github as dropwizard-guice-jpa-seed.

Disclaimer: Of course you might find out that something can be done in a better way. In this case don't hesitate and help me to improve the code! Use the usual pull request mechanism at Github to do so. The same applies for extensions of the functionality!

Notes for developers:

Start the application with the class "ToDoApplication" with the parameters "server todo.yml".

List all tasks with:
GET => http://localhost:8080/task


Add a new task with:
POST => http://localhost:8080/task

Header:
Content-Type:application/json
JSON-Body e.g. :
{"name" : "task 1", "description" : "This is a description"}


Modify a task:
PUT => http://localhost:8080/task/[id]
Header:
Content-Type:application/json
Accept:application/json

JSON-Body e.g.:
{
    "id": "402880944687600101468760d9ea0000",
    "version": "0",
    "name": "task 1 with new name",
    "description": "This is an updated description",
    "finished": "false"
}


Important hint:
I recommend you use the great chrome extension Postman to make such HTTP calls!

Wednesday, August 8, 2012

Technical three-way with Jenkins, Git and Tomcat

The goal was clear: Our Java code shall be regularly compiled by a Jenkins build server, then deployed to our Tomcat server. So far, so good. But implementing this automatic workflow saw quite some obstacles to jump over.

When it comes to code versioning my personal programming past mainly brought me close to CVS and Subversion, but both don't really hold up any more today, so I decided to use git for source code maintenance. And because so many famous projects cannot be wrong, I chose Github as our online hosting service for this.

For professional reasons I am used to my program code being built at least once a day, so the Jenkins build server was an obvious choice. And a Tomcat server for our Java web service should be an easy target to deploy to, or so I thought.