Lol I said for the ‘file of me’. I meant for the life of me.

@kingoftheknoll:

["" (yada/as-resource (io/resource "public"))]

Is there a difference from ["" (bidi/->ResourcesMaybe {:prefix “public/"})] ?

https://github.com/juxt/yada/blob/b9cc97d0e73dd46e962bb51fff83a62c5a18f1fe/src/yada/resources/url_resource.clj It looks like it is buffered/streamed. Hits the client faster

Ah didn’t know that

Me neither 😄. I usually just assume yada is smarter.

Yada resources tend to be superior to bidi's ring handler: they have more metadata to work from, benefit from the async interceptor model and are more scaleable while being more http friendly

@dominicm thanks. If that’s the case then the manual in everyplace it talks about serving an index.html file it’s incorrect. https://juxt.pro/yada/manual/index.html#_declaring_your_website_or_api_as_a_bidi_yada_tree

@kingoftheknoll It's still correct and valid here:

["index.html"
   {:summary "A list of the products we sell"
    :methods
    {:get
     {:response (file "index.html")
      :produces "text/html"}}}]

If you want a Summary (for swagger this is a way to do it.)

if you search the file for “index.html” you’ll find that same example used 3 times.

Hmm, I only see that one. And (yada/handler (new java.io.File "index.html"))

I’m sorry 2 times. ^ that is the second. That one didn’t work for me either. I’m guessing for the same reason.

@kingoftheknoll Does it not work in your project you mean?

excuse me, yes. It’s probably that I just don’t understand how to use java.io.File. I had attempted (yada/handler (new java.io.File “public/index.html”)) which is where my html file was in my resources dir.

And I tried (yada/handler (io/file "public/index.html”)) where I aliased the namespace.

ah. Yeah, it's a bit confusing. Took me a long time to figure it out.

(io/file "resources/public/index.html") will work in development, if you start in the right location. Most production targeted applications will want to use (io/resource) and pull the file off the classpath.

Understanding the distinction between a file and a resource is the key here I think.

For those of you (like us) using yada and itching to try the clojure.spec kool aid: https://twitter.com/juxtpro/status/778291184250880000

@kingoftheknoll I've been on client site today, sorry about the issue you've been having with (yada/as-resource (io.file ...)) - I gather from the thread that the problem isn't so much serving the file but the fact that in deployment the file doesn't exist on the working directory (or rather, it's in the uberjar). Is that right? This is a thing with Java, files are always relative to the current working directory, resources are on the classpath (or in the uberjar if you've deployed one)

In the beginning (1995) there were only directories full of class files. Then Sun invented the JAR (because HTTP connections didn't have keep-alive and each class downloaded to the browser took ages, even over those amazing 28.8K modems we had. Then they invented 'resources', which allowed you to access things in the classpath. But there were still files too.

Then Clojure came along and they invented uberjars (because they'd already used JARs to ship Clojure source code and needed somewhere to put all the aot compiled code)

@malcolmsparks that makes a lot of sense. Like you said what I’m lacking in context having clojure be my first real introduction to the Java ecosystem. Thanks for laying it out for me!