Article: A Clojure REPL in Production

A REPL to a production service can be used to help with debugging (code issues, performance, etc) or in the more niche aspect of updating a live application.

Debugging

Clojure code can be evaluated using the REPL connection to the production service, allowing a way to inspect the state in the service and the results of calling functions, ideally functions that do not change the state of the service.

New versions of function definitions can be (carefully) updated to include instrumentation, e.g. additional logging, taps>, bench-marking, etc.

Data fixes

Migration libraries are excellent for managing changes to a database schema, but less suitable when ad-hoc changes to the data is required. Data fixes should only be run once and the change is not rolled back. Any changes to the data should only role forward.

A script is one approach for a data update, although this requires the script to access the service over an API or directly accessing the database.

A Clojure snippet provides a way to update the data used by service is a more appropriate. These snippets could drive SQL queries to check data, apply fixes and check the fixes were successful.

Data fixes are more effective on-the-fly via the REPL rather than doing it as a data migration as part of the next build/deployment.

Data fixes should be part of an audit trail, so that changes are tracable.

Changes should be applied in a test/staging environment and tested before being applied to production.

Production Use Case

A deployed service includes a REPL connection, either nREPL or Socket server. The REPL connection port should not be exposed on the network configuration of the production server.

Use an SSH tunnel, ideally over a VPN, to access the REPL. This would work with most Clojure editors.

This makes the REPL access as secure as any other services running on that server.

The REPL provides full control of the running JVM process as well as the Clojure code. Therefore great care should be taken.

Live patching code and data

live patch should be low risk.

Live patching is more appropriate when its not possible to wait for the next test/deployment cycle

Services with complex and/or manual deployment steps can benefit more from applying a live patch, especially if zero downtime for that service is important.

Upcating non-clojure systems

This approach could also be used for services that are not written Clojure, but have a connection to their persistent store (e.g. environment variables, java.properties). This is relatively simple with JVM based services, adding suitable Clojure tooling (e.g. Clojure CLI) to the deployed environment

Socket REPL configuration

Socket REPL can be configured using JVM options at startup for a process to spawn a REPL on any given port.
Any account with shell access can stop/start the socket server process and get a REPL going and have that level of access.

The issue contains proposed article content but names no target file or documentation entry point. First confirm the intended article location and editorial scope, then review the Clojure REPL, production-access, live-patching, and audit-trail guidance. Done requires an agreed, publishable article with explicit acceptance criteria.