Chapter 7. Dealing with state
This chapter covers
- Configuring Play for an optimal connection to a relational database, and accessing the database with jOOQ
- Creating custom requests and actions and using them with the client-side session
- Command and Query Responsibility Segregation and Event Sourcing (CQRS/ES)
One of the biggest practical hurdles of switching from a traditional application-server development model to a scalable model such as Play is solving the problem of working with state in a stateless architecture. The server-side deployment of a Play application is meant to be stateless—it doesn’t keep any state in memory other than that for the requests currently being processed. This is in keeping with the philosophy of reactive web applications:
- Stateless server nodes can be interchanged at will without having to worry about keeping client state or other state alive, making it much easier to switch out faulty nodes.
- The overall memory consumption—and, as a result, throughput—of stateless server nodes is much better than that of stateful counterparts.
But where is the state kept, then? Client-side state in Play is pushed to the client (using cookies and possibly other storage local to the client, such as HTML5 storage). Server-side state is typically stored in a database of some kind, and server-side caches are dealt with using dedicated, networked caching technologies.