Someone recently asked about how to deploy Racket web apps on the Racket Slack. The most common answers were install Racket on the target machine, then ship your code there or use Docker (basically a “portable” variant of option 1). I wanted to take a few minutes today and write about my preferred way of deploying Racket apps: build an executable with the application code, libraries and assets embedded into it and ship that around.

Yesterday I released http-easy, a high-level HTTP client for Racket. I started working on it after getting annoyed at some of the code in my racket-sentry package. The same day I wrote that code, someone started a mailing list thread asking for a “practical” HTTP client so that served as additional motivation to spend some time on this problem. Here’s a basic example: 1 2 (require net/http-easy) (response-xexpr (get "https://example.

In The Missing Guide to Racket’s Web Server, I said that dispatch/servlet is equivalent to: 1 2 3 (lambda (start) (lambda (conn req) (output-response conn (start req)))) That was an oversimplification. It does apply its start argument to incoming requests and it does take care of writing the responses to the appropriate connections, but it has another important job: to handle responses returned from continuations and to dispatch incoming requests to captured continuations.

A little over a year ago, I wrote about how you could use the GitHub’s new-at-the-time Actions feature to test Racket code. A lot has changed since then, including the release of a completely revamped version of GitHub actions and so I thought it was time for an update. A Basic Package Say you’re working on a Racket package for computing Fibonacci sequences. Your main.rkt module might look something like this:

Racket’s package manager doesn’t currently have the notion of locking package sets to specific versions1 per project so, as someone who operates a couple production Racket applications, I’ve been concerned about the possibility that new deployments could introduce bugs in production due to changing dependencies. To solve this problem, over the past weekend I’ve put together a service that creates daily snapshots of the official package catalog. You can find it at racksnaps.

For a project that I’m working on, I have a custom flake id spec that allows me to generate unique, sortable identifiers across computers without any sort of synchronization. The ids themselves can be encoded down to 16 bytes and I wanted to store them in Postgres. A good way to do that is to leverage Postgres’ UUID data type, which lets you efficiently store any 16 byte quantity in a way that can be indexed reasonably well.

Yesterday, I announced rackcheck, my new property-based testing library for Racket and I wanted to do a quick dive into one of the examples in the rackcheck repo where a simple web API is integration tested using PBT. You can find the full example here. The app being tested is a simple leaderboard HTTP API with 3 endpoints: GET /players: lists all the registered players in order from highest score to lowest.

I’ve been playing around with property-based testing in Racket this past week. I started by forking the existing quickcheck library to try and add support for shrinking, but I quickly realized that I’d have to make a number of breaking changes to get it to work the way I wanted so, in the end, I decided to start a new library from scratch. The library is called rackcheck and you can grab it off of the package server.

Racket’s built-in web-server package is great, but parts of it are low-level enough that it can be confusing to people who are new to the language. In this post, I’m going to try to clear up some of that confusion by providing some definitions and examples for things beginners might wonder about. Servlets A servlet is a function from a request to a response. It has the contract: 1 (-> request?

I’d been meaning to play with Racket’s built-in sandboxing capabilities for a while so yesterday I sat down and made Try Racket. It’s a web app that lets you type in Racket code and run it. The code you run is tied to your session and each session is allocated up to 60 seconds of run time per evaluation, with up to 128MB of memory used. Filesystem and network access is not permitted and neither is access to the FFI.