Efficiently Transforming JDBC Query Results to JSON

NOTE The DispatcherServlet class mentioned below has been renamed to WebService since this article was originally written.

A lot of enterprise data is stored in relational databases and accessed via SQL queries. Many web services are little more than HTTP-based wrappers around such queries.

Unfortunately, transforming query results to JSON so it can be consumed by a client application often involves numerous inefficient steps, such as binding each row to a data object and loading the entire data set into memory before serializing it back to the caller. This type of approach has a negative impact on performance and scalabilty. Each row requires multiple heap allocations and constructor invocations, increasing latency and CPU load. Worse, the caller does not receive a response until the entire data set has been processed.

Further, since each response is loaded entirely into memory, high-volume applications require a large amount of RAM, and can only scale through the addition of more physical hardware. Eventually, the garbage collector has to run, slowing down the entire system.

A much more efficient approach is to stream response data. Instead of copying the query results into an in-memory data structure before sending the response, the web service can write a row of data to the output stream each time a row is read from the result set. This allows a client to begin receiving the data as soon as it is available, significantly reducing latency. Also, because no intermediate data structures are created, CPU and memory load is reduced, allowing each server to handle a higher number of concurrent requests. Finally, because fewer heap allocations are required, the garbage collector needs to run much less frequently, resulting in fewer system pauses.

Introducing HTTP-RPC

HTTP-RPC is an open-source framework for implementing REST services in Java. It is extremely lightweight and requires only a Java runtime environment and a servlet container. The entire framework is distributed as a single JAR file that is less than 30KB in size, making it an ideal choice for applications such as microservices where a minimal footprint is desired.

DispatcherServlet

HTTP-RPC’s DispatcherServlet type provides an abstract base class for REST-based web services. Service operations are defined by adding public methods to a concrete service implementation.

Methods are invoked by submitting an HTTP request for a path associated with a servlet instance. Arguments are provided either via the query string or in the request body, like an HTML form. DispatcherServlet converts the request parameters to the expected argument types, invokes the method, and writes the return value to the output stream as JSON.

The RequestMethod annotation is used to associate a service method with an HTTP verb such as GET or POST. The optional ResourcePath annotation can be used to associate the method with a specific path relative to the servlet. For example, the following class might be used to implement a web service that performs a simple addition operation:

@WebServlet(urlPatterns={"/math/*"})
public class MathServlet extends DispatcherServlet {
    @RequestMethod("GET")
    @ResourcePath("/sum")
    public double getSum(double a, double b) {
        return a + b;
    }
}

The following request would cause the method to be invoked, and the service would return the value 6 in response:

GET /math/sum?a=2&b=4

JSONEncoder

The JSONEncoder class, which is used internally by DispatcherServlet to serialize response data, converts return values to their JSON equivalents as follows:

  • CharSequence: string
  • Number: number
  • Boolean: true/false
  • Iterable: array
  • java.util.Map: object

Note that collection types are not required to support random access; iterability is sufficient. This is an important feature, as it allows service implementations to stream result data rather than buffering it in memory before it is written.

ResultSetAdapter

HTTP-RPC’s ResultSetAdapter class implements the Iterable interface and makes each row in a JDBC result set appear as an instance of Map, allowing query results to be efficiently serialized as an array of JSON objects.

For example, consider a web service that returns the result of a SQL query on this table, taken from the MySQL sample database:

CREATE TABLE pet (
    name VARCHAR(20),
    owner VARCHAR(20),
    species VARCHAR(20), 
    sex CHAR(1), 
    birth DATE, 
    death DATE
);

A method to retrieve a list of all pets belonging to a given owner might be implemented as shown below. Note that the example uses HTTP-RPC’s Parameters class to simplify query execution using named parameters rather than positional values. Also note that the method uses JSONEncoder to explicitly write the results to the output stream rather than simply returning the adapter instance, to ensure that the underlying result set is closed and system resources are not leaked:

@RequestMethod("GET")
public void getPets(String owner) throws SQLException, IOException {
    try (Connection connection = DriverManager.getConnection(DB_URL)) {
        Parameters parameters = Parameters.parse("SELECT name, species, sex, birth FROM pet WHERE owner = :owner");

        parameters.put("owner", owner);

        try (PreparedStatement statement = connection.prepareStatement(parameters.getSQL())) {
            parameters.apply(statement);

            try (ResultSet resultSet = statement.executeQuery()) {
                JSONEncoder jsonEncoder = new JSONEncoder();

                jsonEncoder.writeValue(new ResultSetAdapter(resultSet), getResponse().getOutputStream());
            }
        }
    } finally {
        getResponse().flushBuffer();
    }
}

A response produced by the method might look something like this, where each object in the array represents a row from the result set:

[
  {
    "name": "Claws",
    "species": "cat",
    "sex": "m",
    "birth": 763880400000
  },
  {
    "name": "Chirpy",
    "species": "bird",
    "sex": "f",
    "birth": 905486400000
  },
  {
    "name": "Whistler",
    "species": "bird",
    "sex": null,
    "birth": 881643600000
  }
]

With just a few lines of code, query results can be quickly and efficiently returned to the caller, with no intermediate buffering required.

More Information

This article introduced the HTTP-RPC framework and provided an example of how the ResultSetAdapter class can be used to efficiently transform JDBC query results into JSON. For more information, see the project README.

Simplifying Auto Layout in iOS with MarkupKit

Auto layout is an iOS feature that allows developers to create “responsive” user interfaces; i.e., applications that automatically adapt to device size, orientation, or content changes. An application built using auto layout generally has no hard-coded view positioning logic, but instead dynamically arranges user interface elements based on their preferred or “intrinsic” content sizes.

Auto layout in iOS is implemented primarily via layout constraints, which, while powerful, are not particularly convenient to work with. This article provides an overview of how constraints are typically managed in an iOS application, and then discusses some alternatives that can significantly simplify the task of working with auto layout.

Storyboards

The structure of an iOS user interface is commonly represented by XIB files or storyboards created using Xcode’s Interface Builder utility. This tool allows developers to lay out an application’s user interface visually using a drag and drop metaphor.

For example, the following is a storyboard representing a simple view. The view contains two subviews whose positions will be automatically determined at runtime based on layout constraints. The constraints pin the subviews to the edges of the parent view as well as to each other, with a 16-pixel gap in between:

Running the application in portrait mode on an iPhone 8 produces the following results:

In landscape, the application looks like this:

While storyboards are undoubtedly the most common way to create auto layout constraints in iOS, they are not necessarily the most efficient. Using Interface Builder to visually establish every relationship can be awkward, especially when working with large or complex view hierarchies. Further, storyboards are not stored in a human-readable text format, which makes it difficult to identify changes across revisions.

Programmatically Defined Constraints

In addition to storyboards, constraints can also be managed programmatically. For example, the following Swift code produces the same results as the previous example:

// Red view
let redView = UIView()

redView.translatesAutoresizingMaskIntoConstraints = false
redView.backgroundColor = UIColor(red: 202.0 / 255.0, green: 53.0 / 255.0, blue: 56.0 / 255.0, alpha: 1.0)

view.addSubview(redView)

// Blue view
let blueView = UIView()

blueView.translatesAutoresizingMaskIntoConstraints = false
blueView.backgroundColor = UIColor(red: 59.0 / 255.0, green: 85.0 / 255.0, blue: 162.0 / 255.0, alpha: 1.0)

view.addSubview(blueView)

// Constraints
NSLayoutConstraint.activate([
    NSLayoutConstraint(item: redView, attribute: .top, relatedBy: .equal,
        toItem: topLayoutGuide, attribute: .bottom,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: redView, attribute: .bottom, relatedBy: .equal,
        toItem: bottomLayoutGuide, attribute: .top,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: redView, attribute: .leading, relatedBy: .equal,
        toItem: view, attribute: .leadingMargin,
        multiplier: 1.0, constant: 0.0),

    NSLayoutConstraint(item: blueView, attribute: .top, relatedBy: .equal,
        toItem: topLayoutGuide, attribute: .bottom,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: blueView, attribute: .bottom, relatedBy: .equal,
        toItem: bottomLayoutGuide, attribute: .top,
        multiplier: 1.0, constant: 0.0),
    NSLayoutConstraint(item: blueView, attribute: .leading, relatedBy: .equal,
        toItem: redView, attribute: .trailing,
        multiplier: 1.0, constant: 16.0),
    NSLayoutConstraint(item: blueView, attribute: .trailing, relatedBy: .equal,
        toItem: view, attribute: .trailingMargin,
        multiplier: 1.0, constant: 0.0),

    NSLayoutConstraint(item: redView, attribute: .width, relatedBy: .equal,
        toItem: blueView, attribute: .width,
        multiplier: 1.0, constant: 0.0),
])

Because the constraints are established in code, it is easy to identify changes between revisions. Unfortunately, managing constraints programmatically is not particularly convenient. This simple layout required the definition of eight individual constraints. More complex layouts could quickly become untenable.

Stack Views

The UIStackView class, introduced in iOS 9, provides an alternative to managing constraints directly. Stack views automatically arrange their subviews in a vertical or horizontal line, and can be nested to create sophisticated layouts.

For example, the following code uses a stack view to produce results identical to the first two examples:

let view = UIStackView()

view.isLayoutMarginsRelativeArrangement = true
view.spacing = 16

// Red view
let redView = UIView()

redView.backgroundColor = UIColor(red: 202.0 / 255.0, green: 53.0 / 255.0, blue: 56.0 / 255.0, alpha: 1.0)

view.addArrangedSubview(redView)

// Blue view
let blueView = UIView()

blueView.backgroundColor = UIColor(red: 59.0 / 255.0, green: 85.0 / 255.0, blue: 162.0 / 255.0, alpha: 1.0)

view.addArrangedSubview(blueView)

// Width constraint
NSLayoutConstraint.activate([
    NSLayoutConstraint(item: redView, attribute: .width, relatedBy: .equal,
        toItem: blueView, attribute: .width,
        multiplier: 1.0, constant: 0.0),
])

While it is arguably more readable than the previous version, this example is still somewhat verbose. It also still requires the explicit creation of a layout constraint to manage the width relationship, which is not ideal.

Introducing MarkupKit

MarkupKit is an open-source framework for simplifying development of native iOS and tvOS applications. Among other things, it provides a collection of UIView subclasses whose sole responsibility is managing the size and position of their respective subviews:

  • LMRowView – arranges subviews in a horizontal line
  • LMColumnView – arranges subviews in a vertical line
  • LMAnchorView – optionally anchors subviews to one or more edges

These classes use layout constraints internally, allowing developers to easily take advantage of auto layout while eliminating the need to manage constraints directly.

For example, the following code uses an instance of LMRowView to replicate the results produced by the previous examples. The weight property is used to ensure that the views are the same width. This property, which is added to UIView by MarkupKit, specifies the amount of excess space the view would like to be given within its parent view, relative to all other weights. Since both views are assigned a weight of 1, they will each be given 1 / (1 + 1), or one-half, of the available space:

let view = LMRowView()

view.spacing = 16

// Red view
let redView = UIView()

redView.backgroundColor = LMViewBuilder.colorValue("#CA3538")
redView.weight = 1.0

view.addArrangedSubview(redView)

// Blue view
let blueView = UIView()

blueView.backgroundColor = LMViewBuilder.colorValue("#3B55A2")
blueView.weight = 1.0

view.addArrangedSubview(blueView)

Like stack views, layout views are easy to work with programmatically. However, unlike stack views, no manual constraint is manipulation required; MarkupKit uses the weight values to automatically establish the width relationship.

Additionally, the colorValue(_:) method of MarkupKit’s LMViewBuilder class is used to simplify color assignment. The logic is still a bit verbose though, and could become difficult to manage as view complexity increases.

Markup

MarkupKit’s namesake feature is its support for declarative view construction. Using markup, the view hiearchy created in the previous example can be represented entirely as follows:

<LMRowView spacing="16">
    <UIView backgroundColor="#ca3538" weight="1"/>
    <UIView backgroundColor="#3b55a2" weight="1"/>
</LMRowView>

The markup is loaded using the view(withName:owner:root:) method of LMViewBuilder. This method is similar to the loadNibNamed(_:owner:options:) method of the NSBundle class, and returns the root element of the view hiearchy declared in the document:

view = LMViewBuilder.view(withName: "ViewController", owner: self, root: nil)

Unlike all of the preceding examples, this version is extremely concise. It is also much more readable: the element hierarchy declared in the document parallels the resulting view hiearchy, making it easy to understand the relationships between views.

For example, the periodic table shown below was constructed using a combination of MarkupKit’s layout views and UILabel instances:

Creating this view in Interface Builder would be an arduous task. Creating it programmatically would be even more difficult. However, in markup it is almost trivial. The complete source code for this example can be found here.

Summary

This article provided an overview of how layout constraints are typically managed in an iOS application and introduced MarkupKit, an open-source framework that can significantly simplify the task of working with auto layout in iOS.

For more information and additional examples, see the MarkupKit README.