Using an ORM library is typically the default choice when using relational databases. Yet what if you don’t want to use an ORM? Despite making life easier in a lot of ways, ORM libraries have their limitations and quirks, and inevitably obscure your view into the resulting SQL, which often results in inefficient queries.
So let’s say you want to avoid using an ORM, but would rather not write raw SQL everywhere either. One option is to use a query builder library such as jOOQ, Squirrel or Knex. Query builder libraries provide a relatively thin abstraction over SQL, but make writing queries more convenient and – crucially – composable.
In the project I’ve been working on for the past year, we use Knex on top of PostgreSQL, which provides first-class JSON support. In this blogpost, I’d like to illuminate how we utilize some of PostgreSQL’s JSON functions to help with managing relations without an ORM.
First, let’s consider the following very simple data model:

Imagine that we want to fetch a person with id 1, along with the person’s hobbies, including the category of each hobby. The desired result should look something like this:

Using an ORM library such as Bookshelf (which internally uses Knex), one needs to only define the models and their relations, after which actually fetching the desired result is as easy as this:

Knex has no concept of models, so accomplishing the same result would involve fetching the desired Persons, their Hobbies and Hobby Categories, and mapping them together manually in the service layer to provide the desired result. That’s a fair bit of work.
What we would like to do is to write one query that returns the entire desired object graph in the correct format. As it happens, PostgreSQL provides JSON building functions that help accomplish exactly this: row_to_json, which turns a single row into a JSON object with column names as keys, and json_agg which does the same for multiple rows and returns the results neatly in an array. Similar functionality can be achieved in MariaDB/MySQL, but not as conveniently.
Let’s first consider the case of fetching a Hobby and its associated Category. We need a query for each:

Using the row_to_json-function, we can now get the Category as a subquery within the Hobby query:

The single row returned from the subquery is turned into an object and embedded within the main result, and we get the following result, exactly as we wanted:

Now let’s consider the second case of fetching a Person and their Hobbies. This is a many to many relation, so we need to a use a join to a junction table in the subquery:

Now we embed the subquery like before, but using the json_agg-function instead:

Again, the results look exactly as we wanted:

So we are now getting the results in the form we want with just SQL – all we need to do is to combine the two queries. Since we’ve seen the raw SQL, let’s translate it into Knex. First, let’s define a function for each table that returns the basic contents of the table:

We can then compose them together:

Running the query will return the following results:

Which is the exact result we originally wanted.
With a bit of work (the exact details of which are outside the scope of this blog), you can extend Knex’s query builder function to get the final query to look something like this:

For anyone proficient in SQL, this is quite readable and fairly easy to pick up.
If you really wanted to, you could even define some specialized classes named after your tables that contain query logic as well as knowledge of relations that you’d commonly want to include, so you could eventually end up with something even more readable like this:

Jokes aside, this basic approach has worked very well in my current project. Although using an ORM would undoubtedly have made basic queries simper to write, with PostgreSQL basic queries are not a problem regardless, and there’s a tendency for an ORM to become an obstacle whenever trying to achieve something more complicated. Although you can generally fall back to raw SQL or a query builder even with an ORM, sticking close to SQL by default makes you think of how to solve your problems with SQL in general, resulting in better queries and improved SQL skills for solving those complicated cases. If your ORM is causing you headaches, I’d gladly recommend sticking to a query builder and utilizing the capabilities of your DBMS.

TL;DR Prefer map and filter over forEach when you need to copy an array or part of it to a new one.
One of the best parts for me in the consulting line of work is that I get to see countless projects. These projects vary widely in size, the programming languages used and in developer competence. While there are multiple patterns that I feel should be abandoned, there is a clear winner in the JavaScript world: forEach to create new arrays. The pattern is actually really simple and looks something like this:

const kids = [];
people.forEach(person => {
  if (person.age < 15) {
    kids.push({ id: person.id, name: person.name });
  }
});

What is happening here is that the array for all people is processed to find out everyone aged less than 15. Each of these ‘kids’ is then copied to the kids array by selecting a few fields of the person object.
While this works, it is a very imperative (see Programming paradigms) way to code. So what is wrong? you might be wondering. To understand this, let’s first familiarize ourselves with the two friends map and filter.

map & filter

map and filter were introduced to JavaScript already quite a while ago as part of EcmaScript 5.1 in 2011. They are methods of arrays that allow a more functional style coding in JavaScript. As usual in the functional programming world, neither of the methods is mutating the original array. Rather they both return a new array. They both accept a single parameter that is of type function. This function is then called on each item in the original array to produce the resulting array. Let’s see what the methods do:

• map: the result of the function called for each item is placed in the new array returned by the method.
• filter: the result of the function called for each item determines whether the item should be included in the array returned by the method.

They also have a third friend in the same gang but it is a little less used. This friend’s name is reduce.
Here are simple examples to see them in action:

const numbers = [1, 2, 3, 4, 5];
const doubled = numbers.map(number => number * 2); // [2, 4, 6, 8, 10]
const even = numbers.filter(number => number % 2 === 0); // [2, 4]

Now that we know what map and filter do, let’s next see an example of how I would prefer the earlier example to be written:

const kids = people
  .filter(person => person.age < 15)
  .map(person => ({ id: person.id, name: person.name }));

In case you are wondering about the syntax of lambda used in map, see this Stack Overflow answer for an explanation.
So what exactly is better with this implementation:

• Separation of concerns: Filtering and changing the format of the data are two separate concerns and using a separate method for both allows separating the concerns.
• Testability: Having a simple, pure function for both purposes can easily be unit tested for various behaviours. It is worth noting that the initial implementation is not as pure as it relies on some state outside of its scope (kids array).
• Readability: As the methods have clear purposes to either filter out data or change the format of the data, it is easy to see what kind of manipulations are being done. Especially as there are those functions of the same category like reduce.
• Asynchronous programming: forEach and async/await don’t play nicely together. map on the other hand provides a useful pattern with promises and async/await. More about this in the next blog post.

It is also worth noting here that map is not to be used when you want to cause side effects (e.g. mutate global state). Especially in a case where the return value of the map method is not even used or stored.

Conclusions

Usage of map and filter provides many benefits such as the separation of concerns, testability, readability and support for asynchronous programming. Thus, it is a no-brainer for me. Yet, I constantly encounter developers using forEach. While functional programming might be a little scary, there is nothing to be afraid of with these methods even though they have some traits from that world. map and filter are also heavily used in reactive programming that is used nowadays more and more in the JavaScript world too thanks to RxJS. So next time you are about to write a forEach first think about the alternative approaches. But be warned, they might change the way you code permanently.

Dev track scope

Presentations

Conclusions

I recently had to implement Amazon Cognito JWT authentication with Spring Boot, and since I wasn´t able to find any clean & simple guides with quick googling, I decided to write my own. In this blog post, I´m going to walk you through the steps of the process I used.
We are going to implement a Spring boot application that is able to authenticate the user against Amazon Cognito using OAuth 2.0 authorization code grant and JSON Web Tokens. All code examples are written in Kotlin.
This post is not going to cover Cognito itself. I expect you to know what Amazon Cognito is and how to configure it.
NOTE: This is a practical guide with lots of code examples. For the sake of simplicity, the code contains only the necessary components for the authentication to work, and you are expected to add more features for it to be safe & efficient in a production environment.
Ok, so let’s get started.

Settings & dependencies

First, we need to set up some dependencies. Spring boot starter web & security are pretty obvious, and Nimbus JOSE + JWT is a library which we are going to use to handle the JSON Web Tokens.

 
Next, let´s define some properties:

Here we specify:

• Base URL for Cognito authentication
• Endpoint URLs for authorization and token requests
• Cognito client_id
• Cognito client_secret
• Cognito callback_uri
• URL of Cognito public keys

You´ll get all these values from your Cognito configuration.

Authentication

The next step is to define a processor bean for tokens and configure it to use the specified keys URL as a key source. This bean is responsible for processing and verifying the token, and extracting the authentication details. Most of the work is done under the hood, so not much manual configuration is needed at this point. Basically, we just need to set the key source and algorithm (which is RS256 in this example).
example).

We also need to set up a filter which filters all our authenticated requests, extracts the token from headers, and sends it for processing. The filter is also responsible for denying any requests that don´t contain a valid token. We first try to extract the token from the Authorization header and then extract the actual authentication and claims. If the token is valid we then manually set the Spring Security Context and let the request go forward. We´ll also catch any exceptions thrown by the processor in case the token is not valid, and respond with 401.

Next, we need to define the user endpoints for authentication requests. We need two endpoints: one for redirecting the user to the Cognito login form (which after successful login redirects the user to callback uri with authorization code), and other for retrieving the actual token with the authorization code. This way the client does not need to know almost anything about Cognito beforehand. Redirect to login form is handled with a basic redirect response, and the token is retrieved by sending a POST request to Cognito´s /oauth2/token -endpoint with the authorization code and client id. We´ll set up a service for that. We also need a model for Cognito JWT:

Accessing the claims

Now all that is left is to access the token claims inside the application. We´ll specify a model class for the claims and update our AuthService with a method for extracting these claims from security context (note that the claims must, of course, match the ones you´ve set up when configuring Cognito).

To access the claims anywhere inside spring context, we simply inject our AuthService class and use the getClaims method. Let´s test it by writing a basic controller which returns the extracted claims back to the client:

Logging in and accessing protected endpoints

You should now be able to log in and access the protected /user/me -endpoint.
 
Steps for logging in and using protected endpoints:
1. Send GET request to /auth/login.
2. Follow the redirect and login to Cognito to get the authorization code.
3. Send a GET request to /auth/token?code={code}, and copy the id_token parameter from the response.
4. Send a GET request to /user/me containing Authorization header with value ‘Bearer {id_token}’.
 
Code for a fully working demo is available at:
https://github.com/akselip/spring-cognito-demo