Clojurians Log v2

Hello there, I'm testing out yada and stumbled onto the edge project. I'm eager to use it as a base, but am wondering what is the "recommended" approach to extending this? Should I be creating my own app folder, or does it make more sense to carve out my own namespace under the existing src folder?

Hello. Start adding namespaces under app

Makes sense. What about configuration? Where would you say is the best place to shift the system over to using a customized config.edn? Is it sufficient to move the existing config to config.edge.edn and start my own config.edn?

Our advice is too add to config.edn until you are familiar with the setup, then gradually take away the phonebook and other components.

Cool, that's exactly what I was after. Thanks for the help 🍻

Another quick question: what is the recommended deployment strategy for edge? I'm still pretty new to deps.edn, so I'm unfamiliar with how building/deploying happens with this setup.

I normally lean on Heroku to host my Clojure projects. Would that still make sense here? What does juxt normally lean on?

(Side note: I'm really loving the use of aliases in edge. This is a very promising way to structure projects, so thank you for a great example.)

I haven't added it yet, but packaging with pack is something I need to do. Then heroku shouldn't be absolutely terrible. We had to cheat with heroku and a build pack when we used it.

Quick google brought me here: https://github.com/juxt/pack.alpha Lambda is a close second as far as deployment preferences go. Is Lambda a good candidate for running yada/edge, or would a less transient server be required?

yada + lambda don't play together. There's not a ring abstraction for lambdas yet to my knowledge, yada would need that as a minimum to start working, and then an async layer on top of that.

Hm I see...maybe "Dockerizing" the app and running on Beanstalk would be a path-of-least-resistance :thinking_face:

We've done heroku with edge, but not published it. If you're comfortable with heroku, that's a good way to do it. We generally deploy to EC2.

I'll give it a try. Out of curiosity, what were the "cheats" you made to the buildpack? Were they JVM tweaks?

No, no. It's just that the clj cli tool is not yet in any heroku build packs. We had to use a buildpack which runs an arbitrary bash script, which installs clj and then does the build.

#!/bin/sh

cd $BUILD_DIR/app

curl -O <https://download.clojure.org/install/linux-install-1.9.0.358.sh>
chmod +x linux-install-1.9.0.358.sh

mkdir cljlocal
./linux-install-1.9.0.358.sh -p cljlocal

./cljlocal/bin/clojure -R:build -m io.dominic.krei.alpha.main production "static"

./cljlocal/bin/clojure -Sdeps '{:deps {pack/pack.alpha {:git/url "<https://github.com/juxt/pack.alpha.git>" :sha "bb2c5a2c78aca9328e023b029c06ba0efdd1e3b7"}}}' -m mach.pack.alpha.capsule deps.edn $BUILD_DIR/foobar.jar static/ foobar 0.0.1

https://github.com/weibeld/heroku-buildpack-run with this I believe (uncertain)

But you have to chain this buildpack also with the java one I think.

Ahhh ok that makes sense. Thanks for this!

No problem 🙂 We really need to document this stuff.

Does Yada support Transfer-Encoding: chunked requests?

I tried to write a handler that uses :consumer but that consumer never gets called when a request comes in with Transfer-Encoding but no Content-Length

I think I identified at least one bug relating to that here: https://github.com/juxt/yada/blob/master/src/yada/interceptors.clj#L174

but I'm not sure if I can just patch that line to something like (or (get-in request [:headers "transfer-encoding"]) (and content-length (pos? content-length)))

because in that case there would need to be code that actually parses the chunked encoding protocol which I don't see any evidence of in Yada