Since there was a question about deploying Racket code using Docker on the Racket Reddit this morning, I figured I’d write a quick follow-up to my post about Deploying Racket Web Apps. My preference is still to avoid using Docker and just use the method described in that post by default. But, if I have to use Docker for some reason, then I’ll typically use a two-stage build to build a distribution in the first stage and then copy that distribution into the second stage in order to get a minimal Docker image that I can easily ship around.

If you’ve looked at some of the concurrency and networking procedures available in Racket, you might’ve noticed a bunch that follow the naming pattern <name>/enable-break and it might not have been immediately obvious why or when you would use these variants of these procedures over the regular ones. Let’s look at a snippet from the documentation of tcp-accept/enable-break:

I’m currently stuck waiting for a flight, so I figured I’d pick up where I left off yesterday ¹ and implement a couple more of the Protohackers challenges.

Someone on the Racket Discord recently mentioned the Protohackers project and I figured it’d be fun to write about Racket solutions to the challenges available on the website.

Racketfest 2023 was held yesterday and I gave a short talk about building native apps with Racket. Nothing new if you’ve read my recent posts, but below is a transcript. A recording might also be posted later, in which case I’ll update this post to link to it.

A couple of releases back, I added support for schema registries to Franz. Some of its users use Protocol Buffers to serialize their data, so I needed to be able to support that use case. So, I wrote a parser for the proto2 and proto3 specs and a minimal serializer/deserializer implementation that doesn’t require code generation on top of that. You can find the package and docs on the Package server and the source on GitHub.

In anticipation of working on the Windows & Linux versions of Franz, I’ve wanted to move its auto-update implementation from Swift into Franz’ Racket core. The reason I implemented the auto-update code in Swift in the first place is because of the way the Swift part normally communicates with the Racket part: the core Racket code runs in its own thread and the Swift part communicates with it asynchronously via pipes. So, until a couple of days ago, I didn’t have an easy way for Racket code to trigger the execution of Swift code on its own.

All of the code that handles embedding Racket inside Swift, code generation and the general communication mechanism is open source and lives in Noise, so that’s where you can find the full implementation of the approach I describe in this post (specifically, commits 0a585be and 2f6c37e).

This post is a dumb rant, but I needed to vent.

Some of the feedback I’ve received on Franz so far has been that folks need support for more compression and serialization formats. In that vein, here are some Racket libraries I’ve released in the past couple of weeks:

I’ve been using Apache Kafka for about a year now and I’ve wanted a desktop client from the beginning. I couldn’t find one I liked – the best I’ve found is Confluent’s Cloud UI, but that’s neither a desktop app, nor is it a great experience1 – so, a couple months ago I started building a native macOS GUI for Kafka in my spare time and, today, I’m proud to announce the first beta release of Franz.