Introduction

Here are four JSON APIs which offer the same functionality – an endpoint that retrieves 10 items, connected with randomly selected users via user_items, in JSON format.

The Database

The APIs are backed by a PostgreSQL database items_api_development that has three tables. The database, tables, and data are created from within postgrest-items-api, as noted below.

Here is the schema:

users

1+------------+--------------+------+-----+---------+----------------+
2| Field      | Type         | Null | Key | Default | Extra          |
3+------------+--------------+------+-----+---------+----------------+
4| id         | bigint       | NO   | PRI | NULL    | auto_increment |
5| email      | varchar(255) | NO   | UNI | NULL    |                |
6| created_at | datetime(6)  | NO   |     | NULL    |                |
7| updated_at | datetime(6)  | NO   |     | NULL    |                |
8+------------+--------------+------+-----+---------+----------------+

user_items

1+------------+-------------+------+-----+---------+----------------+
2| Field      | Type        | Null | Key | Default | Extra          |
3+------------+-------------+------+-----+---------+----------------+
4| id         | bigint      | NO   | PRI | NULL    | auto_increment |
5| user_id    | bigint      | YES  | MUL | NULL    |                |
6| item_id    | bigint      | YES  | MUL | NULL    |                |
7| created_at | datetime(6) | NO   |     | NULL    |                |
8| updated_at | datetime(6) | NO   |     | NULL    |                |
9+------------+-------------+------+-----+---------+----------------+

items

1+------------+--------------+------+-----+---------+----------------+
2| Field      | Type         | Null | Key | Default | Extra          |
3+------------+--------------+------+-----+---------+----------------+
4| id         | bigint       | NO   | PRI | NULL    | auto_increment |
5| name       | varchar(255) | NO   | UNI | NULL    |                |
6| created_at | datetime(6)  | NO   |     | NULL    |                |
7| updated_at | datetime(6)  | NO   |     | NULL    |                |
8+------------+--------------+------+-----+---------+----------------+

• user_id and item_id in the user_items table are foreign keys to users.id and items.id respectively
• There is a non-unique index on each foreign key
• There is a unique index on users.email, and one on items.name

The Applications

• rails-items-api, the popular rack-based Ruby framework
  • Rails 7.x
  • Oj Optimized JSON Gem
  • ActiveRecord ORM, the default ORM for Rails
  • Puma application server
• sinatra-items-api, a lightweight Ruby framework, which I’m running on rack
  • Sinatra 4.x
  • oj Optimized JSON Gem
  • Puma application server
  • Sequel ORM
• go-items-api, a Go HTTP server, using Go’s standard library
  • Chi router
  • sqlx, a thin wrapper around Go’s database/sql package
• postgrest, a PostgreSQL plugin
  • Webserver, router, etc. are inside the plugin
  • Any table or view in your DB is available as a JSON REST endpoint

Install / run instructions are in the READMEs at the root of all four apps. Once you install all four, you can run performance tests yourself; the Go app has a performance tester that fires up 10 concurrent Go http clients, does 1000 total requests against all four APIs, and prints performance results. Your results will vary from mine.

The same PostgreSQL database is the backend for all four. It is created, migrated, and seeded inside postgrest-items-api.

I’m using these four apps as a starting point to discuss performance, simplicity, extensibility, and ease-of-use for these and potentially other frameworks and languages. This post is just an introduction; in future posts, I’ll talk about issues around

• Tuning each of these applications
• Writing performant queries
• Routing
• Middlewares
• Auth
• Object allocations
• Managing database connections
• Much more

Initial Results / Observations

1000 requests @10 concurrent workers

Here is a laundry list of mixed pluses / minuses for each app:

Go

• Virtual tie with Postgrest
• Type safety
• Go http scales very simply. There is no strict limit to the number of goroutines Go’s http server will spawn
• Raw SQL only – no ORM

Postgrest

• Virtual tie with Go
• Remarkably simple implementation
• Server, DB, config, all-in-one
• Poor routing capabilities, anything like api/v1 has to happen upstream inside Nginx / load balancer

Sinatra

• Virtual tie with Go
• Remarkably simple implementation
• It’s just as simple to write raw SQL within Sequel as it is to use its ORM features
• Much more obvious than Rails what each component is doing, and, as you add components, much more obvious what’s slowing down performance
• Can be implemented (as I have) as a rack app, so we can mount any other Rack app (Rails, custom Rack app, another Sinatra app) inside our app

Rails

• Use of the ORM is more strongly encouraged than in Sequel; it’s a bit more difficult to implement raw SQL in ActiveRecord than it is in Sequel
• Amazingly easy to set up a Rails API project and do many powerful things (Rake tasks / workers, crons, websockets, mailers, etc.)
• Can be quite difficult to implement many intermediate - advanced features in SQL and in Rails
• Includes lots of bells and whistles that we might want to use one day (websockets, Rake tasks/workers)
• We get environments (test, development, production, ++) done very nicely out of the box

In future posts, I’ll be tuning all three of these apps, introducing more features and performance monitoring, and demonstrating various upgrade paths. Stay tuned!