Linux backend services - esy, nix, opam

Ecosystem
,
1

If you were creating a new backend service like twitter / mastodon, had a limited budget, and only needed to build for linux docker images, ignoring the front end, would you use esy, nix, or opam?

I have been pondering this and I haven’t come to a conclusion yet.

I don’t have plans to create another mastodon. I am just going through the thought exercise.

2

What is a ‘backend service like twitter / mastodon’? What would it do?

3

Something like the following:

  • Have a REST api accepting POST and GET requests to create a tweet, retrieve tweets by user, register a follower, get feed
  • The service will talk to persistence systems like Cassandra or some equivalent
  • Dozens of containers based on a docker image containing the service executable will be deployed to kubernetes or a similar service
4

Ah, OK. I’d say it’s a personal preference. Different people have different toolkits they turn to. I’d probably use Esy because that’s what I’m using for ReWeb.

1 Like
5

It sounds like you would just be using it to manage dependencies, in which case probably any of them would work (although nix seems like a bit of an odd choice unless you have a particular attachment to it). I use opam for a project like this (REST API deployed as docker image) and it’s fine. Setting up building in docker was a little difficult at first although it might be easier nowadays. It’s also slightly annoying how opam is designed for packages, not applications (e.g. you get warnings if you don’t fill out fields specifying maintainer/license, when you really just want to specify dependencies). I don’t know what esy is like in comparison.

1 Like
6

In terms of selecting compatible dependency versions, as I upgrade in the future, do these options sound right:

  • opam w/lock file - delete lock file, hope the solver selects versions that work well together (relying on community opam ci efforts to iron out incompatibilities between packages before I encounter them)

  • esy - delete lock directory, remove any version bounds from package.json, and hope that the solver selects versions that work well together (relying on same as above, maybe some additional issues with missing esy opam overrides and esy ci possibly catching issues before me)

  • nix - rerun opam2nix, similar to opam steps above

I wonder if nix will provide any additional value in selecting compatible versions, beyond simply running opam solver regularly.

7

For opam I would track dependencies with partial versioning in an opam file (possibly generated from dune-project), then use a lockfile for your CI builds that you regenerate when you update the opam file.

1 Like
8

With esy, when you upgrade dependency versions, it automatically adjusts the lockfile. You don’t need to manually delete it.

1 Like