No, it's not related with bindings

The issue is that with-open closes the file before the lazy sequence is realized

But, bindings have a similar effect, in that the bound variable is released before the lazy sequence had a chance to use it

That's only true of you capture the binding, but if you capture the bound value you're good

Yes, you're right, that's what I was trying to say.

Both of them create a scope, outside of which you'd better not reference the bound vars, and lazy sequences make it easy to make that mistake.

But still, the end result is that lazy sequences shouldn't be used with side effects. That means they shouldn't use any global var, be them dynamic or not. And they shouldn't use a file either or anything else that's a side effect

If they're realized before exiting the scope, why not?

I still think the problem is when they escape the scope.

Well, carefully using them sure. But, what you're effectively describing is using lazy sequence eagerly :p

Since you're going to realize them before they are needed

So I find learning to use the eager fns instead for side effect is a good practice

Those would be: doseq, dotimes, run!, mapv, filterv, etc.

And transducers as well

It's fine to wrap a doall around a lazy-seq too, assuming you're careful that nested lazy seqs are also wrapped and all that

Yes, that's the kind of thing I was referring to.

But, all I can say is, when I was a more beginner Clojure dev, I'd use a ton of doall, and now I don't think I used a doall in the last year

Same goes for dorun

Nothing wrong with them, but I guess I just got the instinct to use other things instead

I understand, thanks.

I guess I also just changed the way I code in general as to minimize and isolate most side effect, so that probably contributes to me not using those as much

https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects

Recently I've been using run! as he recommends. But, for example, sometimes I use filter on the source collection, which returns a lazy seq. So I am using a mixture of lazy and strict, which doesn't seem all that bad.

On a side effecting source collection?

No, the source is just data but may be a lazy seq. My point is just that it is not specific enough, and could be confusing to beginners, to say that you can't mix side effects with lazy sequences. I think what would be useful is a more specific description of what to avoid. For example, if we could define exactly what you mean by "side effecting collection", in terms a beginner could understand, that might help. But I think that is actually not so easy to understand. IMO even beginners need to read about and understand laziness and its pros and cons, as described in Stuart's page for example. A one liner that just says "don't mix them" I think isn't enough.

Or at least, it wasn't enough for me as a beginner.

Maybe I'm wrong, maybe it is enough to say: Don't use any function that produces a lazy sequence to perform side effects. For example, functions passed to map should not perform side effects. However, lazy sequences may be used as inputs to functions such as run! that do not produce a lazy sequence themselves, and the function passed to run! may perform side effects.

Almost one line, if that is really enough as a rule of thumb.

I can see how even understanding what a side effect is can be challenging to a beginner at first

And understanding what a lazy seq is as well

Ya, you may be right. Don't do any side effects inside the function passed to the sequence fns such as map, reduce, filter, remove, etc.

That might be clearer. Where a side effect is making use of any global variable, of any shared mutable container, data-structure, object or binding, and of any IO operation.

Yeah, that seems pretty clear.

There is great wisdom in this one.

Technically, often the code is coupled either way. It's just a question of whether the dependency is clear or hidden. Dynavars don't remove the fact that one piece of code is dependent on the other.

having a chain of N namespaces :require ing each other is a form of coupling, that is forced when going the defn route Component or request storage (those were my words, not "dynavars") allow ns's to not depend so strongly on each other, allowing certain modular designs

sure, make sure to understand my OP

Yeah, I thought you might already understand. Wanted to make it clear.

One solution to this is stamp coupling, but I find the vagueness of that very confusing.

Or, don’t cut arbitrary lines in your code for no concrete gain?

They somewhat exist no matter what :). You have to cut your code somehow.

Do you?

I would argue, for the case of a standard webapp, you basically need: 1) a handler fn for a route, 2) some helper fns. Everything else (e.g. “domain”, “service”, “controller) is an arbitrary, and unhelpful, cut.

Where does a query for a user go? Request function or elsewhere?

How do you divide your handler functions up? Where do they live? By what they operate on? What if they operate on multiple Entities?

(these are genuine questions which I'm in constant pursuit of novel answers too, as I think they help define a strategy very well.)

Query for a user: call a shared fn & pass the data

How you divide up handler functions is just code shuffling.

The only impact it has is, “How fast can I find the fn I’m looking for?” Keep shuffling them until the answer to that is, “It doesn’t bother me.”

As long as handlers aren’t co-dependent (don’t do that), they can be moved ad nauseam with literally zero impact (negligible cognitive overhead, zero runtime impact).

Do you have one big namespace with everything in? How do you decide when to put something in a different namespace?

Seems fine to start with one big one.

I make a new one whenever it feels right 😄

I know that’s not very satisfying. But it’s important to remember: this will not make or break you. It’s arbitrary, and it’s super easy to change.

What I'm confused about is, what division would you use?

I’m saying: first and foremost, it doesn’t matter

after that, like, entity/similar endpoints/whatever-feels-reasonable

The entire point of shuffling is to find things faster. So try to keep an eye on that and update when it “feels slower.”

Interesting. This aligns quite well with something I have been thinking about, that I think is relevant to this decision. Your unit of modularity is the function, not the namespace. (ish).

ish

obviously a lot more goes into real modularity

Equivalent is probably ring/compojure. Some people outgrow those and move to more data driven things like pedestal or compojure.api or yada. Others keep using the basics of ring but maybe swap routers to something like reitit

Httpkit is just an implementation of a ring server. The most popular is embedded jetty but some people opt for undertow, httpkit, tomcat, etc. I'd start with jetty if you're not aware of a reason to choose something else. The jetty implementation is bundled with ring by default

If it really is just CRUD, have you considered https://postgrest.org/en/v6.0/. Apologies for the clojure person years I've just destroyed but I'd still hire them and get them doing more interesting stuff.

@U20DT8LSE My recommendation is to use https://www.hugsql.org/ for clojure + sql. Use sql for what it's good at, then use clojure for dynamically generating functions to call your sql expressions. Your DBA's will love you, and you will be doing basically vanilla SQL + Comments, and you can leverage the full power of the SQL database of your choice (PG in this instance) without fighting an ORM (One of the many classic ORM problems)

This is actually very topical at the moment as I think it's basically what @U050CTFRT was talking about yesterday at re:clojure. We shouldn't be making "artisanal, hand-crafted CRUD APIs", for each company who needs one. We should be writing (or using) an API that can be put in front of any database (or rather any instance of a database of a specific type).

@U20DT8LSE Toucan + Honey SQL

I have used it in couple of my projects and it turned out well..

Simplfied EDN Query Language for SQL. https://github.com/exoscale/seql Turn Clojure data structures into SQL. https://github.com/jkk/honeysql

@U20DT8LSE Clojure alternate to ORM: https://walkable.gitlab.io Demo: https://github.com/walkable-server/realworld

(def app
  (-> (wrap-defaults app-routes api-defaults)
      (wrap-cors :access-control-allow-headers [:accept :origin :user-agent :x-request-with :cache-control :cookies]
                 :access-control-allow-credentials "true"
                 :access-control-allow-origin [#"^(http(s)?://)?localhost:(\d){4}"]
                 :access-control-allow-methods [:get :put :post :options :delete])
      wrap-cookies
      ;; print-request
      (wrap-authentication backend)
      (wrap-authorization backend)
      logger/wrap-with-logger
      (wrap-json-body ,,, {:keywords? true :bigdecimals? true})
      wrap-json-response))

I explicitly returned [] from the function , and in both cases the route/function returns [ ] with application/octet-stream

(defn get-users-events
  [request]
  (if (authenticated? request)
    {:status 200
     :body (json/encode (find-users-events
                         (:user
                          (:identitiy request))))}
    (throw-unauthorized {:message "unauthorized"})))

If you return a non-empty vector, does it work as expected? (to confirm whether the empty sequence is a special case)

it does not, it returns the vector (not empty) but still has content-type octet stream

this is mysterious, because I have another resource that returns json, and they are the same

hmmm, it looked into it, and the other resource also returns octet stream

After looking closely at the other resource I finally got it to work, the issue was that the frontend go-block was misbehaving, and that was where I was testing the interface. Thanks for the help @U04V70XH6

OK, so it's not related to being empty. Ah, OK, I don't think wrap-json-response actually sets the content-type maybe? I seem to recall running into this with some of the middleware and being surprised the content-type is not set automatically...

I didn’t get it to set content-type

though

hmmm, so how would you recommend setting the content-type?

Looking at wrap-json-response it only puts application/json as the Content-Type if it isn't already set...

...so something in the middleware stack is setting the content type for you (probably in the default middleware? And by the time wrap-json-response gets control, there's already a content type...

I’m a bit new to the language 😅

(def app
  (-> (wrap-defaults app-routes api-defaults)
      (wrap-cors :access-control-allow-headers [:accept :origin :user-agent :x-request-with :cache-control :cookies]
                 :access-control-allow-credentials "true"
                 :access-control-allow-origin [#"^(http(s)?://)?localhost:(\d){4}"]
                 :access-control-allow-methods [:get :put :post :options :delete])
      wrap-cookies
      ;; print-request
      (wrap-authentication backend)
      (wrap-authorization backend)
      logger/wrap-with-logger
      (wrap-json-body ,,, {:keywords? true :bigdecimals? true}) wrap-json-response))

maybe setting wrap-json-response before wrap-cors?

wrap-cors should almost certainly be on the outside of the stack but it's wrap-defaults that is setting the content type for you.

that didn’t work…

ah

Middleware ordering is a thorny problem.

haha yeah I’ve had my fair share of frustrations these past few weeks, I must admit 😅

If you are only returning JSON, you can put wrap-json-response closer to your handler than wrap-defaults

good idea 🙂

I would put the json body / response at the top, then defaults, then auth, then logging, then cors.

hmmm still doesn’t set the content-type

Also note that defaults includes wrap-cookies already.

Paste your current middleware stack/wrapping...

(def app
  (-> (wrap-json-response app-routes)
      (wrap-json-body ,,, {:keywords? true :bigdecimals? true})
      (wrap-defaults ,,, api-defaults)
      ;; print-request
      (wrap-authentication backend)
      (wrap-authorization backend)
      logger/wrap-with-logger
      (wrap-cors :access-control-allow-headers [:accept :origin :user-agent :x-request-with :cache-control :cookies]
                 :access-control-allow-credentials "true"
                 :access-control-allow-origin [#"^(http(s)?://)?localhost:(\d){4}"]
                 :access-control-allow-methods [:get :put :post :options :delete])))

I would add some logging middleware between wrap-json-body and wrap-defaults so you can see what headers are set at that point...

That order looks pretty similar to our order at work for an API that always returns JSON...

haha, then it must be something I’m doing wrong outside of the middleware

I’ll publish the calls all the way down to the db call

This:

(GET "/event" request (get-users-events request))

(defn get-users-events
  [request]
  (if (authenticated? request)
    {:status 200
     :body (json/encode (find-users-events
                         (:user
                          (:identitiy request))))}
    (throw-unauthorized {:message "unauthorized"})))

(defn find-users-events
  [user-id]
  (let [response (db/lookup-a-users-events user-id)]
    response))

(defn lookup-a-users-events
  [id]
  (jdbc/query psql-db
              ["SELECT * FROM event WHERE owner = ?" id]))

Ah, you are not letting wrap-json-response handle the JSON conversion. You're doing it yourself, explicitly.

You should not need that json/encode call -- that's the whole point of wrap-json-response

😄

thank you!

Has that fixed it?

it has!

prefectly

perfectly

(the irony of writing perfectly imperfectly)

https://github.com/ring-clojure/ring-json/blob/master/src/ring/middleware/json.clj#L115 -- wrap-json-responseonly takes action if the response is a collection (not a string, which is what json/encode returns).

I really like how helpful the clojure community is. Thank you @U04V70XH6

if it helps, the standard location for the cache is ~/.m2/repository - maybe it's doing something fancy with HOME?

Maybe someone fat fingered it? I always accidentally type ~?.m2

you can imagine def to be a macro like

(defmacro defx [name value]
  (declare name)
  `(intern (find-ns '~(ns-name *ns*)) '~name ~value))

right