Phil Denhoff

Using Rust wasn't a mistake

Phil Denhoff — Mon, 10 Feb 2025 00:00:00 GMT

It was a painful experience.

I originally created Citadel as a Tauri app, using Svelte for the frontend and Rust in the backend. At the start, this worked pretty well — I enjoyed learning about Rust and how it worked, managing references, and writing “performant” software.

At some point, I looked into running the Rust backend as a separate, stand-alone REST API so that you could self host a web version of Citadel. While feasible, it seemed painful. Working with Tokio is annoying for someone whose day job involves writing highly concurrent Elixir and a lot of async Typescript. Why do I have to manage lifecycles? Why am I giving myself this pain? After hours of trying to get async requests working across the app, I gave up. So I shelved the HTTP API and continued working away on Citadel as a desktop app.

Adding features was slow, steady progress. But it often worked in two phases:

Very quick progress in the UI (using tools I am very familiar with)
Very, very slow progress in the small, complicated backend

Every time I wanted to retrieve more data from the existing database schema (Citadel uses an existing schema, derived from Calibre), I had to remember how Rust and the libraries I’m using work. Then, I had to figure out what business rules Calibre expects / follows and then mesh the two to get data out — and the process is even slower when trying to insert new data. All the inherit complexity got lost in the incidental complexity of using Rust.

About a month ago, I came back to Citadel with the plan to start supporting downloading metadata from sources like Hardcover. Calibre supports this (using other providers), Calibre-Web supports this, Citadel needs to. I first tried to make a super-simple prototype in the frontend, but Hardcover blocks requests from localhost, so I had to push it to the backend.

After three hours of trying to get Rust to make a web request in a reasonable, understandable way, I gave up. I doubt Rust is to blame here, but I could not figure out how to use an async runtime like Tokio when making IPC requests via Tauri. The lifetimes got all messed up. I couldn’t find a sync HTTP library, either. I don’t need async HTTP requests! I don’t really care! But the ecosystem has moved to async, and bring your own runtime.

In comparison, the same graphql request in Typescript is trivially easy. I mean, of course it is. There are tradeoffs to that simplicity.

But after looking at the options for Citadel, I’ve landed on migrating the app to Electron. ugh, I know. Electron. Bane of users everywhere, with its non-native UI patterns and 300MB executables. It’s gross! Frankly, I hate it! I started Citadel originally as a Swift app exactly to avoid this problem. I wanted fast, native software. But the pain of not being able to make quick progress because I was learning new tooling outran the joy of learning new tools eventually, and now I’d trade anything to be able to release the features I wanted to add to Citadel over a year ago but couldn’t, because I wasn’t comfortable with my tools.

I’m in do-or-die mode with Citadel. If I can’t start making progress and adding features that I want, I’ll probably stop using it. At that point, who cares if it’s built with Electron or Neutralino or Tauri or Wails or if its native software? This is a hobby project, which I wrote for me. I probably have over a gigabyte of intermediate build artifacts for the Rust build. At this point, trading to an Electron build might save me disk space.

So, while I enjoyed the satisfaction and challenge of writing Rust code, I’m dropping the language from Citadel for now. Maybe a new project will come up where Rust feels like the right choice?

Applying "tradeoffs" across your life

Phil Denhoff — Mon, 07 Oct 2024 00:00:00 GMT

I’ve recently been practicing pragmatism more, searching to find good balances in trade-offs. One very positive side effect from that is how it’s changed my feelings towards dog ownership.

My border collie / aussie shepherd, Search, needs a lot of active brain time. He always needs a job, he needs a good amount of training every day. For a long time, I felt guilty when I didn’t have the energy to satisfy those needs.

I see it differently now. It’s a trade-off. Every day for Search should be a good day. Not every day can be a great day, and if I don’t have the energy today, maybe I can find it tomorrow. Does he really need a park day today, or did he burn off enough energy yesterday? Can we do a longer park day today, and do something different tomorrow? How can I make today a great day for him?

It’s taken such a load off my shoulders. I do want every day to be amazing for him, but he’s a dog. He’ll survive a day or two without crazy active brain time. Actually, he’ll certainly survive a lot of days, but I don’t want to try that.

So I just keep trying to find that balance, every day, where he gets his needs met and I’m doing what I enjoy, and not making dog ownership a chore.

❦

On Prototyping

Phil Denhoff — Fri, 16 Aug 2024 00:00:00 GMT

Over the last month or so, I’ve had two opportunities at my job to build prototypes of existing things that I have extensive experience with. Both prototypes have been extremely helpful in teaching me how the existing systems work. Without building the thing haphazardly and hackily, I wouldn’t understand first-hand the tradeoffs that were made for our existing things.

One prototype gave me the opportunity to learn about the kind of HTTP server Middleware that you only write when first setting up and API. Not a common thing, by any means. It taught me about a new HTTP server library, and how to delicately balance storing information in the context of that request in a way that was actually usable downstream.

The other project taught me about the complexities of orchestrating background job processing, similar to Elixir’s Oban. I learned about Web Workers and their limitations (each is on its own thread, so there’s no shared objects; messages passed between Workers must be contain only primitives, no objects or functions). I practiced writing code that doesn’t crash when things go wrong — crashing in a Web Worker crashes the Bun runtime, which means your server shutdown because a worker failed. That’s almost the antithesis to the Elixir/BEAM runtime — Erlang virtual processess can crash all the time but the OS runtime process will never crash.

When would I need to learn the ins and outs of background job processing? How often does one set up a new HTTP API and need to set it up from scratch? These things don’t come up unless you give them the opportunity.

Create prototypes. Write crappy, throw away code. What if, one day, you want to write a production-ready version? Now you’ve learned the basics, now you can do it. You’ve already made mistakes you can learn from.

You just have to go out and build it.

The Value of Legacy Software

Phil Denhoff — Fri, 19 Apr 2024 00:00:00 GMT

I’ve recently been working on a piece of software, about 10 years old, that is a Shopify app.

It was acquired from an individual who had evidently built it haphazardly and, when bought, the app was heavily invested into. Much was done to bring the UI up to snuff with Shopify’s expectations for good software. Flow (the now-defunct competitor to Typescript) was added. Storybook and other niceties as well.

However, behind all of the UI cleanup, the addition of types in some spots, and a few new features lurks a ball of mud. A ball of mud essentially written by one man, and now maintained by a small team. We add the occassional feature here, and we might fix a bug there, but most of our work on the existing code is reactionary: we must make this change. Shopify is deprecating an API and now we must rewrite the existing API client to use the new API. We are adding new functionality here to sell our product to new markets so we must change this 8-year-old, 800 line function.

What we are not doing is opportunistically improving our legacy code. When adding another layer on top of existing code, we haven’t asked ourselves how we can improve what is already there. Can we get the method under test? Can we split up the method to get some major fraction of it under test? We simply bolt code onto the outside, try to futz as little as possible with the inside bits, and move on.

I don’t think this is healthy for a team, and more importantly, not healthy for a business. When you continue to bolt things onto the outside, you live in a shanty town. You build a ball of mud. Every architecture decision is you, your team, and the existing code that you cannot refactor if you wanted to. The code ends up making more architectural decisions than you do. And, because you cannot control the code, you cannot add the features that you want to. You cannot achieve the timelines that you want to.

So why have a ball of mud? Because it’s profitable. Today, that is the hardest pill for me to swallow, but it’s what I’m learning to accept about businesses. It’s simply not necessary to clean up our work; we can continue making money without changing the ball of mud. Even better, not changing the code minimizes the short-term risk that our changes might break something. Heaven forbid our profitable, unassuming product should run into issues.

What that calculus fails to include is the outsized risk of being prevented from making changes, or slowed down when you can. If a product is in maintenance mode, not touching legacy code is fine. It continues to make money, the occasional bug is squashed, and required changes are made. But when you want to extend a product, in functionality or in market share, you need to be willing to dry out some mud.

❦

golink xsrf error

Phil Denhoff — Thu, 11 Apr 2024 00:00:00 GMT

A recent update of Tailscale’s excellent golink tool broke creating links for me.

Every time I tried to create a new link, I got an error: “invalid xsrf token”.

I tried restarting my browser, going straight to https://go/ instead of the usual https://go.my-tailnet.ts.com, opening golink in a different browser (Safari, instead of Arc), but all to no avail.

So, I rolled back my Docker container to the previous release (see below). Rolling back, suddenly the app worked again. Great! That makes sense, since the most recent release includes changes to how XSRF/CSRF is handled when adding new links.

However, I rolled forward again, to the latest image. And the app works again normally. I don’t know why. If you run into the same issue as I did with golinks, maybe you need to restart the service? Or roll back & roll forward?

I hope that helps!

The version I rolled back to:

ghcr.io/tailscale/golink@sha256:09c8f79a4b7f908337888e0cb4e2c24ec6bbeadb22b9385fefd9f6ed29f5adfe, which corresponds to this commit.

Replacing Calibre

Phil Denhoff — Sat, 13 Jan 2024 00:00:00 GMT

Calibre is an excellent tool — if you believe that a swiss army knife with 95 attachments is an excellent tool.

Calibre, pretty much.

However, if you enjoy being able to reach into your bag, grab your pocket knife and immediately know how to use it, Calibre is the worst tool you could use. That’s why I’ve been writing a backwards compatible replacement for Calibre. It’s called Citadel, and here’s a short demo video.

Watch the Citadel demo video (MP4).

In case you didn’t notice, it’s quite rough!

Citadel, a prototype replacement for Calibre

Citadel is a Tauri desktop app that reads & writes Calibre libraries (SQLite database + existing book files) and helps you manage them. It has a Svelte frontend (that can be run over the internet) and a Rust backend (which supports headless HTTP server mode). Most of the work to read & write Calibre data is in a separate crate called libcalibre, which I hope to separately publish in the future so that others can create robust Calibre tools.

So far, you can:

List all of your books as a cover view or table view
Add a new book
Edit the title of a book
Copy a book to a folder on your computer, e.g. a SD card that’s attached to your computer (for ereaders)

As you can tell, this is incredibly early software with little functionality and a propensity to crash if you look at it wrong (I have a few too many panic-y .unwrap()s).

It’s early days for the project! Calibre has been around for 15 years and has ~450k lines of Python. Citadel has maybe ~3k lines of Rust, and maybe another 1k lines of Svelte/Typescript.

But it’s a prototype, and it’s working today, and I’m slowly replacing my Calibre usage with an app I wrote myself that doesn’t take 8s to boot on an M2 Max Macbook Pro.

Citadel is open-source and on GitHub. There are no release builds yet and it’s only been tested on my M2 Macbook. It should work elsewhere, but if you run into issues please let me know!

Addendum

Why Svelte + Rust?

I picked Rust for the backend because I wanted to learn it. This is a hobby project! I’m allowed to do whatever I want.

For the frontend, I wanted to use something that isn’t React, having been using it at work for 2+ years. I know Vue & Svelte pretty well, and I wanted another project to use Svelte in (besides my Logseq/Raindrop plugin and my Logseq slipbox plugin), so that’s why it’s a Svelte frontend. It’s specifically web-tech because I already know how to write web frontends. I tried Swift before! But it took too long to make progress.

With a native backend, a fast-to-write-and-maintain frontend, the use of native webviews (the binary for macOS is 18MB), and the option of splitting the frontend & backend up to connect them over HTTP, going down this route has been a great choice so far.

A note on `libcalibre`

I’ve separated all of the logic of “how to talk to a Calibre library” into a crate called libcalibre. It’s (experimentally) written applying DDD, but I’m not sure how well I like that.

The crate itself is pretty flexible — you should be able to use it in a CLI tool, or compile it for another language and make a true native e-book library management app. I started doing that before, in Swift, before realising that I was working to learn both Swift as well as all of Calibre’s business logic, which made progress infuriatingly slow.

Android won't get passkeys from other devices... unless you tell it what to get

Phil Denhoff — Wed, 27 Sep 2023 00:00:00 GMT

I’ve been playing around with WebAuthn recently, building an app that uses it as the primary login method. Building out the backend has been interesting — I’m constantly learning new stuff — but the frontend has been exhausting.

Here’s one example. I’ll try to keep it short.

In our flow, we want users to sign in by their username & passkey in one step. Those passkeys might be stored in the platform authenticator or in a remote authenticator: think Android/iOS vs. iCloud/1Password/Bitwarden/another phone.

On Android, if you make a navigator.credentials.get call without providing a list of allowed credentials in the allowCredentials option, we will only get back the platform credentials. If no platform credentials have been set up for the relaying party’s id (rpId), the user will be told they have none, and given no other info or options. Android won’t ask the user if they’d like to use a remote authenticator, like their hardware token or a different phone.

// Android users will not be able to use a remote authenticator for this credential request
await navigator.credentials.get({publicKey: {
	challenge: ArrayBuffer,
    timeout: SIXTY_SECONDS,
    rpId: window.location.hostname,
    allowCredentials: [],
    userVerification: preferred
}});

However, if we do provide a list of allowed credentials, Android will prompt only for USB, Bluetooth or NFC devices — I guess it doesn’t support scanning QR codes from other phones, or password managers?

// Android users can use their BT, NFC, or USB authenticators for this.
// But not other phones.
await navigator.credentials.get({publicKey: {
	challenge: ArrayBuffer,
    timeout: SIXTY_SECONDS,
    rpId: window.location.hostname,
    allowCredentials: [{
      id: RemotelyStoredCredentialId,
      type: "public-key",
      transports: []
    }],
    userVerification: preferred
}});

On iOS, either call works — with or without the list of allowed credentials. The first will look for valid credentials for the rpId, suggest them, and provide an alternative option to use a remote authenticator. The second call, with the list of allowed credentials, will filter out anything local not in that list and, finding that there are no local credentials, suggest using a remote authenticator.

Why is Android like this? I don’t know.

Using Nx to build ReScript libraries for TypeScript apps

Phil Denhoff — Fri, 22 Sep 2023 00:00:00 GMT

I’ve been playing around with Nx recently. At my last job, I migrated all of our Javascript/Typescript code to a monorepo using Nx, and I loved the experience, but I often wondered what it would be like to use other compiles-to-JS languages.

Well, I created nx-with-functional-languages as a kind of public testing ground, to see what the experience would be like with different languages. It took a decent amount of fiddling to get anything working, and I’m still not in love with what I came up with, so I thought I would share what I did in the hopes of inspiring others to extend my work.

Let’s see how we can set up a Node/Express server that uses a ReScript library. ReScript is a strictly-typed language with some niceties over JS, like pipes and pattern matching, but most importantly it’s an example language with its own build system that can generate Javascript (and Typescript) that we can import from our Typescript project. Let’s see what using it looks like.

Creating the Nx workspace

Side note: You can view the final repo on GitHub.

First, we need to create an empty Nx workspace for us to try all this out in. I’m using pnpm here, but you should be able to use yarn, npm, or bun. pnpm dlx is the same as yarn create, npx or bunx.

I’ll call my example workspace org — feel free to use something else, but where I write @org you’ll need to replace it with your workspace name.

(You can skip distributed caching, but for real projects I recommend enabling it.)

pnpm dlx create-nx-workspace@latest org --preset=ts

To get an overview of what we’ve just created,

cd org
ls
git log --oneline
git status

Creating an application and a library package

We’ll need to create some library code, which we’ll later reconfigure as a Rescript project, as well as an application that can use that code. This is the core of Nx — package & dependency management, with some extra caching.

A Node.js server will work well as the application, and Nx has a generator we can run to automatically set that up for us. Rescript is not yet supported (thus, this article) and so we’ll have to hack on top of what we get out of the @nx/js generator to get that working. I don’t want to delete/unconfigure a bunch of extra crap, so ideally we limit the amount of stuff Nx configures for us — no bundler, no test runner, no linting. However, the only way I figured out how all this works was by generating projects with different configs, so I do recommend giving it a go! Just… not for this walkthrough.

Okay, enough preamble, how do we create a nearly-empty JS library that we can hack on?

Creating a basic library

We’ll go with a library name of finance. If, while running this command, you are asked “What should be the project name and where should it be generated”, pick libs/finance.

pnpm nx generate @nx/js:library --name=finance \
  --unitTestRunner=none \
  --bundler=none \
  --linter=none \
  --directory=libs/finance \
  --importPath=@org/finance

With that done (I recommend committing your changes along the way, but I won’t remind you at every step), we need to add some more missing stuff.

Create a package.json like this, in libs/finance:

// libs/finance/package.json
{
  "name": "@org/finance",
  "version": "0.0.1",
  "type": "module",
  "dependencies": {},
  "devDependencies": {}
}

Ensure the type is module, we need that for import resolution later, in our app.

Creating a Node.js app

There’s an Nx generator for Node apps in the @nx/node package, but we don’t have that yet. Install it as a dev dependency (since only developers need it, to generate Node projects):

pnpm add --save-dev @nx/node

Now we can use it: we’ll choose a project name of api and the webserver framework Express. You can use any web framework you like, but you may need to make other changes for this walkthrough.

pnpm nx g @nx/node:application --name=api --framework=express

Dependent builds & bundling

We need to make some changes to how Nx has set up our Node application — by default, when we build our server it won’t automatically build code from monorepo packages it’s dependent on, and the generated file won’t properly reference our finance library.

First, we want to make sure that when we build our Node.js app, Nx goes and builds everything that it depends on first. Within api/project.json, add "dependsOn": ["^build"] to the build target.

Second, we need to make sure that when we build api that the build tool (esbuild, by default) can reference the packages our code will import. The configuration for how we use esbuild is in the Nx config file api/project.json — specifically, within the “build” target. If we left "bundle": false in our esbuild config, we would end up with a generated file (dist/api/main.js) that attempts to require() from a package @org/finance that cannot be found (Why, I’m not sure. Maybe because we generate a new package.json in our esbuild config?). If we don’t generate the package.json, the build fails to import express.

So, we need to ensure that our generated file can reference its imports. One way of doing that is by bundling all of the imports into one giant file, which is what we’ll do. This is less than ideal — debugging is likely to be more difficult unless you correctly set up source maps. What we’re doing here is fine for a prototype, but a more complex system might have issues. If you come up with a better solution, please let me know!

Third, we want to make sure we’re set up to use ES Modules, by changing the format from cjs to esm. Whether we need to use ES Modules is unclear to me, but I had issues importing Common JS modules which were resolved when I swapped to ESM.

Our api/project.json file should end up looking like this:

// api/project.json
{
  "name": "api",
  "sourceRoot": "api/src",
  "projectType": "application",
  "targets": {
    "build": {
      "executor": "@nx/esbuild:esbuild",
      "outputs": ["{options.outputPath}"],
      "defaultConfiguration": "production",
      "dependsOn": ["^build"],
      "options": {
        "platform": "node",
        "outputPath": "dist/api",
        "format": ["esm"],
        "bundle": true,
        // ... snip
        }
      },
      // ... snip
      }
    }
    // ... snip
  },
  "tags": []
}

Finally, update your api/tsconfig.app.json to have "module": "esnext", as we use ES Modules in our libraries.

Using ReScript in `@org/finance`

Our goal is to use ReScript’s build system to build our source code, but wrap it in Nx to get the benefits of caching and dependency management.

We’ll follow the (short) ReScript install guide to get it set up in our project, then create some ReScript source code files, build them by calling the ReScript build system directly, and then wrap that in an Nx task to support caching & dependency management.

Rescript installation

In the project root, run

pnpm add rescript

We also need to add the ReScript version we just installed into our libs/finance/package.json. We can get the version with

cat package.json | grep rescript

And then add it to libs/finance/package.json. Generally, we should not have to do this. If we had an Nx/ReScript plugin, Nx would manage our package.json dependencies automatically for us by inspecting the source code and seeing which dependencies are used.

// libs/finance/package.json
{
  "name": "@org/finance",
  "version": "0.0.1",
  "type": "module",
  "dependencies": {
    "rescript": "^10.1.4"
  },
  "devDependencies": {}
}

Finally, we have to make sure it’s installed in the node_modules in libs/finance by running pnpm install in that folder:

cd libs/finance
pnpm install

Next, we’ll create a Rescript config file (“bsconfig.json”) in libs/finance. Use the config below, which is based on the recommended config but includes a gentypeconfig directive to generate Typescript types when we use the @genType annotation. You can read more about Rescript’s GenType in their docs.

// libs/finance/bsconfig.json
{
  "name": "finance",
  "sources": [
    {
      "dir": "src",
      "subdirs": true
    }
  ],
  "package-specs": [
    {
      "module": "es6",
      "in-source": true
    }
  ],
  "suffix": ".bs.js",
  "bs-dependencies": [],
  "gentypeconfig": {
    "shims": {},
    "generatedFileExtension": ".gen.ts",
    "module": "es6",
    "debug": {
      "all": false,
      "basic": false
    }
  }
}

We want to ensure that we’re using ES Modules, so update libs/finance/tsconfig.json to include module: "esnext", just like we did for our api application.

Our first ReScript source code

Our project is now set up for us to write some basic ReScript source code, commit it, compile to JavaScript & TypeScript, and commit that as well. You might be wondering, “why would we commit our build artifacts?” ReScript recommends it for a number of reasons, including ease of adoption.

Delete libs/finance/src/lib — we don’t need it.

Create a new ReScript file libs/finance/src/TimeValue.res, with the following sample function:

// libs/finance/src/TimeValue.res
/**
  * Compute the future value of an investment using compounding interest.
  * For some principal investment pv, interest rate i, and number of periods n,
  * returns the future value of the investment.
  *
  * @example
  * fv(1000, 0.0675, 20) // => 2896.703652
  */
@genType
let compoundInterest = (pv, i: float, n): float => pv *. (1.0 +. i) ** n

We won’t go over the details of compoundInterest — feel free to use any sample function here.

Now, compile your ReScript file to JS & TS by running pnpm rescript build while in the libs/finance directory. You should see two new files in libs/finance/src: TimeValue.bs.js and TimeValue.gen.ts. This is what our api application will use. However, it’s not yet available as an export from our library.

Note: you’ll also see a new libs/finance/lib folder — you can .gitignore this. It’s build information for ReScript, but we don’t need to keep it around AFAIK.

To make the exports available, we’ll add them to our libs/finance/index.ts. Update it to this:

// libs/finance/index.ts
export * from './TimeValue.gen';

Here, we’re exporting only the TypeScript code, to ensure that downstream callees call the right function. We could instead export from “TimeValue.bs”, but that would export only the JavaScript code, which is not really what we want — it has no type safety.

Note: do not include the .ts extension. Our api build does not support including it.

With Rescript building our code manually, let’s look at adding our build as an Nx task.

Building ReScript with Nx

We’re going to use the “nx:run-commands” executor for our build, which allows to run arbitrary shell commands in our target. This isn’t the Nx Way™ — ideally, we would have a ReScript plugin that controls our build — but that won’t stop us from building a prototype that could be improved later. With the “nx:run-commands” executor, we can call the command pnpm rescript build in the finance project, tuning what we cache and when.

Edit the libs/finance/project.json to look like this:

// libs/finance/project.json
{
  "name": "finance",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "libs/finance/src",
  "projectType": "library",
  "targets": {
    "build": {
      "executor": "nx:run-commands",
      "inputs": [
        "{projectRoot}/src/index.ts",
        "{projectRoot}/src/**.res"
      ],
      "outputs": [
        "{projectRoot}/src/index.ts",
        "{projectRoot}/src/**.bs.js",
        "{projectRoot}/src/**.gen.ts"
      ],
      "options": {
        "commands": [
          "pnpm rescript build"
        ],
        "cwd": "libs/finance"
      }
    }
  },
  "tags": []
}

The major addition is the new build target, using the nx:run-commands executor. We tell Nx that the “inputs” (which files, when changed, invalidate the cache) are all the .res files in our project, as well as the index.ts. At the same time, the generated output files that should be read from the cache (if the inputs match) are all .bs.js and .gen.ts files. We tell Nx to run the pnpm rescript build command when we run our build task; we could add more commands to the array if we needed to, say, copy files around. We also set the current working directory (cwd) of the task to the project’s directory, libs/finance.

Okay, nice! That’s all we need to have Nx run the build of our ReScript source code. You can run it with pnpm nx build finance from the repo root. The build will not work from the libs/finance directory.

If you run it again, it should take almost no time as Nx detected the inputs had not changed. If you keep the index.ts and .res files the same, and delete the .bs.js and .gen.ts files, and re-run the build, it should also take almost no time. Nx will read the output files out of its cache instead of running the ReScript compiler.

Using ReScript code in a Node.js app

So, reviewing what we’ve done so far: we have ReScript source code that Nx will build for us. The build generates TypeScript from ReScript, and our Node.js app can reference that TS. Why don’t we try it out?

Open your api/src/main.ts and import & call compoundInterest. You can log the value immediately, or put it in an HTTP response — we’ll do both. Your file should look like something this:

import express from 'express';
import { compoundInterest } from '@org/finance';
 
console.log(compoundInterest(100, 0.05, 10));
 
const host = process.env.HOST ?? 'localhost';
const port = process.env.PORT ? Number(process.env.PORT) : 3000;
 
const app = express();
 
app.get('/', (req, res) => {
  const computed = compoundInterest(100, 0.05, 10);
  res.send({ message: computed});
});
 
app.listen(port, host, () => {
  console.log(`[ ready ] http://${host}:${port}`);
});

If we run the server with pnpm nx serve api, we should see Nx run the @org/finance build, then start the Node server. The server should print out the value in the log, and if we get localhost:3000/, we should see the value in the response.

The log:

$ pnpm nx serve api
 
> nx run api:serve:development
 
[ watch ] build succeeded, watching for changes...
Debugger listening on ws://localhost:9229/c73ad56e-881c-490c-95fd-886518b7fad2
Debugger listening on ws://localhost:9229/c73ad56e-881c-490c-95fd-886518b7fad2
For help, see: https://nodejs.org/en/docs/inspector
 
162.88946267774423
[ ready ] http://localhost:3000

Via the api:

$ curl localhost:3000
{"message":162.88946267774423}⏎

We’re done! Our Node.js app is able to call functions that we wrote in ReScript. ReScript builds TypeScript & JavaScript code that our Node app’s build system, esbuild, can use. We use Nx to put both in one repo. It’s just that easy.

What now?

Here are some ideas for follow-up improvements (please let me know if you do these!):

Put all of this into a ReScript plugin for Nx
Find some way to avoid having to bundle all of our server into one file
Add more languages. Civet, maybe?