Point-Free, a Swift site whose server is written as pure functions with effects at the edges

Three packages, and why the split matters

The codebase is split into three pieces, and the split is the lesson. The PointFree package is the core application, responsible for routing requests, loading data and rendering HTML and CSS. The Styleguide library contains the functions and data types for creating a consistent style across the entire website, which in practice means the design system is a package rather than a folder of view files. The Server package is the actual executable server, and it uses NIO to handle the low-level server responsibilities and hands everything else over to the PointFree package. That division is the whole architecture in one sentence: the transport layer knows about sockets, the core knows about a request and a response, and the boundary between them is where effects are allowed to happen. The primary language is Swift, the licence is MIT, and the project ships a video tour of the codebase as an episode on its own site for anyone who would rather watch than read.

git clone https://github.com/pointfreeco/pointfreeco.git
cd pointfreeco

Pure functions at the core, side effects at the boundary

The first of the fun things to explore is the one that explains the rest. Web pages are developed in playgrounds for a continuous feedback loop, and this is made possible by the fact that the entire server stack is composed of pure functions with side-effects pushed to the boundaries of the application. The consequence is that any request can be loaded in isolation, including POST requests, all without ever worrying about doing a side-effect. A POST request is the case that normally forces a database into the middle of a handler, and here the handler itself is a value that can be evaluated in a playground, with the database access represented as an effect that the runtime performs only when the request is actually served. This is why the testing story below works, and it is also why the project is worth reading as an example: the same property that lets a page be previewed live also lets a request be asserted on in a test.

It allows us to load up any request in isolation, including `POST`
requests, all without ever worrying about doing a side-effect.

Snapshot testing a whole request lifecycle

The second thing worth exploring is snapshot testing, and the project pushes the idea further than the usual screenshot comparison. They use swift-snapshot-testing to capture full data structures in order to verify their correctness. Not only do they do this in the traditional way of taking screenshots of web pages at various break points, on iPhone and on desktop, but they can also snapshot any entire request-to-response lifecycle. The example in the project documentation shows exactly what that artifact looks like: a step with a response ended, the request that was made including the POST URL and the posted email field, and the response with its status and location header. So a regression in the routing or in the redirect behaviour shows up as a diff in a text file rather than as a failed page assertion. They use this on everything from middleware, to ensure requests are correctly transformed into responses, to entire web pages, to make sure the site looks correct at a variety of sizes.

▿ Request
  POST http://localhost:8080/launch-signup

  [email protected]

▿ Response
  Status 302 FOUND
  Location: /?success=true

Getting it running, and the two system dependencies

The setup instructions are unusually concrete. You clone the repository, and then you need two things that are not Swift packages. The first is cmark, the CommonMark parser, which is installed with Homebrew, and the second is Postgres, which is the database of choice and has to be installed and running, with a make target that creates the user and the two databases. There is a note for people using Postgres.app, EnterpriseDB or another installation method, pointing them at the CPostgreSQL readme for the extra steps. The check step is what makes the setup pleasant: the Makefile has a check-cmark target that verifies the binary is on the path, a check-postgres target that verifies psql is present and that a server actually answers, and a bootstrap target that depends on both along with the local configuration file. With the project open in Xcode you can run the server locally by selecting the Server target and pressing Command+R, then visit localhost:8080, and you can explore the playgrounds by selecting the PointFree target and building it.

brew install cmark # or your preferred installation method
brew install postgres # or your preferred installation method
brew services start postgresql # or your preferred launch method
make db

The Makefile as the project's entry point

The Makefile is a good example of a project that treats the developer experience as a feature. The default target is bootstrap, which depends on the cmark check, the Postgres check and the local environment file. The checks are chatty about what they are doing, warning when a dependency is missing and confirming when it is present, which is friendlier than a Makefile that fails with a raw command not found. The db target creates the superuser and both the development and test databases, and there is a matching db-drop target that removes them, and the two are written with a trailing or true so that running them twice does not fail. The stripe-listen target installs the Stripe CLI if it is not present and then forwards the invoice and customer subscription events to a local webhook endpoint, with a print-json flag, which is the standard way to develop against a payments provider without touching production.

stripe-listen: /usr/local/bin/stripe
	stripe listen \
		--events invoice.payment_failed,invoice.payment_succeeded,customer.subscription.deleted \
		--forward-to localhost:8080/webhooks/stripe \
		--latest \
		--print-json

The container image, and the two Dockerfiles

There is a Dockerfile and a Dockerfile.local, and the difference is instructive. The main Dockerfile is a two-stage build on the swift:6.3 base image, with the build stage installing build-essential, cmake, libpq-dev, libz-dev and python-is-python3, then copying Package.resolved, Package.swift, Sources and Tests, and building two products in release configuration with debug symbols: the Server and a Runner. The final stage is the slim swift:6.3-slim image with the client libraries installed, and it copies the cmark headers and library out of the build stage explicitly, so the markdown parser travels with the image rather than being installed from a package manager. The Server and Runner binaries are symlinked into the path and the container command is Server. The compose file shows the local variant, with a Postgres service on port 5433 configured with a trust auth method and a web service built from Dockerfile.local that points at the database through a DATABASE_URL and exposes port 8080.

services:
  db:
    environment:
      POSTGRES_DB: pointfreeco_development
      POSTGRES_HOST_AUTH_METHOD: trust
      POSTGRES_USER: pointfreeco
    image: postgres
    ports:
      - '5433:5432'

The libraries it stands on

The project lists the open source it builds on, and the list is a map of the Swift server ecosystem the team works in. swift-html is a Swift DSL for type-safe, extensible and transformable HTML documents, which is what makes the rendering in the core package type safe rather than string concatenation. swift-web is a collection of types and functions for dealing with common web server concerns, such as HTML render, CSS preprocessing and middleware. swift-prelude offers a standard library for experimental functional programming in Swift, which is the vocabulary the pure core is written in. swift-tagged helps create strong contracts at data boundaries, like JSON from GitHub and Stripe and the PostgreSQL data, so a raw string cannot be passed where a typed value is expected. swift-snapshot-testing powers the testing infrastructure. A separate CC-LICENSE.md at the root, alongside the main LICENSE, suggests the content is licensed separately from the code.

swift-html
swift-web
swift-prelude
swift-tagged
swift-snapshot-testing

Maintenance, and what to expect from the repository

The repository is not archived, and the last push was on 2026-10-14, so the site is actively built. There are no GitHub releases, which is unsurprising for a website rather than a distributed library, and the versioning story lives in Package.resolved, the Swift package manager lockfile, which pins every dependency revision the site builds against. The topics attached to the repository are education, server-side Swift, snapshot testing, Swift and Swift playgrounds, and those four words describe it accurately: this is a teaching company whose website is also its teaching material. The Xcode color theme used in the episodes is in the repository as a make target, and a color theme file sits at the root. The one historical note worth knowing is that Brandon gave a talk about most of the core ideas that went into the project at Swift Summit 2017, on server-side Swift from scratch, which is a useful companion to the code for understanding why the architecture is shaped the way it is.

Sources/
Tests/
PointFree.playground/
workers/

Editorial conclusion

Adopt this repository as a reference if you are writing a server in Swift and want to see what the pure core with effects at the boundary looks like in a real codebase rather than in a tutorial, and skip it if you want a site to run, because it is a single company's publishing platform with its own database, its own design system and its own content pipeline. Verify three things before you try to build it: that you have Postgres running, since the project states it is the database of choice and the Makefile checks for a live server before it will proceed; that cmark is installed, since the markdown parser is a system dependency rather than a Swift package; and that you are on Swift 6, since the container images are built on the swift:6.3 base and the badge in the project page names Swift 6.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pointfreeco/pointfreeco on GitHub
4. Project website
5. README