Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-08-14

Channels

#hyperfiddle
<
2023-08-14
>
braai engineer12:08:38

Not Electric-related but for my Electric app: how are guys deploying uberjars in the wild? At the moment, I'm running a GH build runner on my prod machine, on successful build, delete old uberjar, download build artifact and cycling SystemD service. Without going full K8s, is there a nicer blue/green deployment strategy that plays nicely with Clojure apps? cc @robert-stuttaford are you using Immutant perhaps?

nakkaya13:08:06

I build a docker image on the CI and deploy that. Develop on a branch where CI only runs the unit tests then when merged into master CI will build a docker image, SSH into my prod machine pull the image and restart the container.

braai engineer14:08:56

(btw. Java / Clojure is already virtualized – don't need Docker. I ditched it - less complexity)

frozenlock14:08:10

I'm doing pretty much the same: uberjar, overwrite the jar on prod server, restart service. Simple, fast, efficient.

frozenlock14:08:37

I've worked with teams that would waste weeks/months of developer time building a deployment chain... "chaining" themselves to a particular ecosystem.

braai engineer14:08:00

Know any tricks to speed up uberjar build? My (relatively simple) Electric app takes 4 minutes to build on GH actions standard-sized box. Parallelising cljs & clj is the natural start.

frozenlock14:08:49

No sorry. Currently all my prod apps are Clojure only or built with Reagent in the case of SPAs. I hope to go deeper in Electric soon.

robert-stuttaford07:08:08

our production build. we use buildkite and our own babashka scripts to orchestrate everything. ">" in this listing means 'wait for everything to the left before starting the stuff on the right':

👍 2
braai engineer07:08:17

@robert-stuttaford haven't used Buildkite. Any advantages over GH Actions? (I'm principally wary of putting too many eggs in one basket with GH)

robert-stuttaford07:08:51

its agents run on our EC2 instances, so we can control perf and keep everything inside our security cordon

👍 2
braai engineer07:08:21

btw. GH Actions has self-hosted runners

robert-stuttaford07:08:51

we built this system before GHA was a thing 🙂

robert-stuttaford07:08:23

we only use GH for source hosting, we don't really use PRs or any of that jazz

👍 2
braai engineer07:08:10

junk in da trunkkkk

braai engineer07:08:04

Jujutsu has similar first-class conflicts https://github.com/martinvonz/jj

braai engineer07:08:55

I'm holding out for a Lisp-syntax aware VCS that has first-class conflict resolution so whitespace changes do not add noise. Just let the client format their code maybe with metadata about how they want it formatted.

braai engineer19:08:25

How to support multiple manifests / frontends in one Electric project? I want to split my app in two: thin view for anon clients and thicc view for admins, but same project. I could make a separate project, but different ports and other annoyances. I've added another shadow-cljs build, which compiles, but index.html module templating is the same and I see admin namespaces in the "client" manifest. Ideally I would like the client connection be keyed on namespace or build ID and then I only get the AST stuff I need for a particular frontend. In meantime will probably combine the two and do different routing for the time being with an /admin route.

Dustin Getz16:08:28

from this perspective Electric apps are ordinary shadow-cljs apps

Dustin Getz16:08:46

so check your :require graph