thanks @seancorfield for weighing in, at this point after looking at some of the options, I think I might go with HugSQL (or YesQL) since these give me the right blend of magic and flexibility

Some of the more experienced DBAs would be helping me so I guess it’d be nice to give them the flexibility they need with SQL queries

I am going to watch the HoneySQL video and see where it takes me

@verma: strongly recommend honeySql. As your domain evolves, your queries will get more complex. You’ll keep having this scenario where “I want the same as this other query, except… x” where x in (add new select field, add another where clause, 100 other minor tweaks). In this scenario, having your SQL query represented as a clojure map is really helpful, as it’s programmable

i always take the opposite view. especially if you have dba's, if you are writing in some DSL and not SQL you are alienating people who can help you. It also means you can't profile, test, and develop the queries against the standard clients (SSMS for us with MS Sql Server), and then you run up against aggregates not working correctly, perhaps unicode/ascii casts that get expensive, etc. For all but the simplest tasks i always prefer to write my own queries

@verma: Yes, I think if you're going to be working with DBAs then you want something that will let you work primarily with SQL directly.

I recently added an :explain? option to java.jdbc so you can get a report from (most) DB of how a query will work for a DBA to review. Something I've been asked for several times and just haven't figured out a good way to handle it is the ability to retrieve or print the actual SQL sent to the DB (which is useful when dynamically building queries such as with HoneySQL).

We've found :explain? "explain extended" very useful with MySQL...

(the default :explain? true is equivalent to :explain? "explain")

@grzm: are you grzm on twitter?

alexmiller: this is not what I’m using, but what my libraries that I hope other people will use will depend on.

@pupeno: I think adding :scope "provided" to your clojure & clojurescript dependencies makes your library users get the version they want

gerrit: ahhh… 🙂 thanks.

hello, what would be the disadvantage of targeting node with cljs instead of using Java with clojure?

I mean node is pretty fast and lightweight

and what would be a replacement for tomcat that would mimick the one thread scerario of node

http://www.infoworld.com/article/2883328/java/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html I've found this link that helped me out

@vinnyataide: smaller server-side ecosystem for ClojureScript than Clojure; slightly restricted Clojure language features (macros are less dynamic etc); but most importantly, the differences between the JVM and NodeJs as platforms

but not equivalent to clojure

@vinnyataide: if you’ve got a library that can provide thread-safe datastructures (clj) why not take advantage of a multi-threaded server? What would a single-threaded http-server give you?

@val_waeselynck: thanks

@vinnyataide: in particular, sometimes you do like to use blocking IO

(but maybe I didn’t understand the point :))

nah, I like my code horizontal 😜

I mean with callbacks and such, but I see the importance of branched interactive scripts

and other things

@gnejs: the speed of node is because of the single thread service afaik

@vinnyataide: performance comes from async IO rather than single threading per se. node.js scales well compared to old-skool java servlets because it does not use a thread per request and thus uses less RAM. However, having async IO plus MT means that you can use more of the hardware without going into cluster mode in node.js

The biggest problem with enterprisey java servers are that they are not written with async/reactive in mind. Neither are the older applications running on them. Netty/Jetty/Undertow are implemented differently. Vrooooom. And can utilize multiple CPUs from one process.

niiiiice

that's a really nice answer

@vinnyataide: have a look at Yada too https://github.com/juxt/yada

I got a friend that deployed a service in node and told me that It went 30% less resources than other alike that was in java

@vinnyataide: there's no doubt here, NodeJs generally has a smaller footprint

especially for IO-heavy loads

very nice lib

so the architecture that I'm building that is message based is comming through is datomic as database, yada server with om next, and front end with om next with secretary for routing. Is that right?

I saw apache kafka as a message pub service but Idk how it would fit since I've never used it

@vinnyataide: sounds good! Since you're interested in making non-blocking apps, keep in mind that Datomic will prevent you from going full-async for reads, because loading segments from storage to local cache is synchronous; however, thanks to pervasive caching there won't be that much IO at all and the latency should be low (writes are asynchronous on the other hand).

@vinnyataide: IMHO Kafka is better for event streams rather than messaging (i.e. recording events rather than using messages to put work on a queue)

@raymcdermott hmm that's good to know

@val_waeselynck: yeah that's okay for me

@vinnyataide: AMQP is typically better for messaging (with Kafka you have to manage consumers into different partitions so you’re starting with a hack)

@vinnyataide: HornetQ's pretty good too, and another reason to use the JVM 🙂

well the whole problem that I'm trying to solve is live reports for my clients

cool, so many options, I'm kinda new to the java ecosystem

I'm not going yet into these, but I'll take a look at it later, the writes are my focus right now, the queries and sync will be focused later, I know that with om next I can do that with complete decoupling

FYI you can now link to individual messages on the Clojurians slack log, e.g. https://clojurians-log.clojureverse.org/clojure/2015-06-04.html#inst-2015-06-04T13:03:37.002003Z

with props to @grzm

(still regenerating all the static html so give it a minute)

looks like I'll be choosing sente as a lib only solution for the reports

In clojurescript I can write this predicate:

(defn deref? [x]
  (satisfies? IDeref x))

(instance? clojure.lang.IDeref x)

Ohh, I see. Thanks. That's confusing: cljs.core/IDeref in clojurescript and clojure.lang.IDeref in clojure.

IIRC in clojure/jvm IDeref the java Interface was written before protocols were introduced to the language. Clojurescript tends to make more use of protocols.

I had read that somewhere. But this makes it more concrete, thanks.

probably backwards compatibility is holding clojure/jvm back a bit in that respect

it’s more then that - would imply re-working a significant portion of the code base

gja: what you’re saying does make sense, but I am in no way an SQL expert, so would rely on people who do this for a living, I’d have to decompose our DBA’s queries and then recompose them using clojure data structures while considering re-usability and composition, also the DBAs may send me updates to queries which I’d have to rework again, I will take a look at HoneySQL and see if it changes my opinion 😕

seancorfield: that makes sense, I will take a look at it, thanks :thumbsup:

@plexus: thanks for pulling this 🙂

@verma @dpsutton you can always translate to sql, and have DBAs profile it. HoneySQL does do a very good job of correctly casting things, much better than I do myself, personally. But if the DBAs are giving you the raw SQL, and you are sure that you’ll never make any changes, then i’d pick HugSQL.

we had a complicated-ish query that had a few group-by's and an aggregate, maybe max or sum, over microsoft sql server. honey lacked that at the time, if it doesn't still lack that

thanks for weighing in gja :thumbsup:

oh just found out they did have the aggregates, but they aren't called aggregates. You use % to specify functions

@dpsutton: even if it lacks that kind of thing, it’s really easy to extend

HoneySQL is a good choice when you want to do some basic composition of queries programmatically, and/or do a lot of substitution of fields or variables

per gja’s point, definitely makes sense to use something like HugSQL if you are basically going to drop some queries in and use them without much variation—in that case HoneySQL is too much work I think

i’m using honeysql for building up queries from common patterns this week — working quite nicely

@dpsutton: for more complex function calls there is honeysql.core/call

Hope you guys don’t mind us spamming #C03S1KBA2 a little. #C051WKSP3 just closed a seed round to bring a managed, clojure first, data solution to the masses http://www.onyxplatform.org/jekyll/update/2016/08/17/Funding.html

I'm using honeysql as the backbone for a very complex query editor

based on user input I have to rope in one to twelve joins, columns, etc

it works wonderfully

Is there something that lets me call a Clojure server from a ClojureScript front-end, as if it was in the same process, but only assuming EDN arguments and return values? Some kind of RPC-like framework?

@sdegutis: cljs-http is perfectly fine for this

why do you need it to feel like RPC? past experience has taught me that trying to hide HTTP usually ends badly 🙂

@robert-stuttaford: Assuming I'm making a ClojureScript SPA, then the backend doesn't really need to have "routes" per se, since the routes are all handled on the front-end, which does all the user-facing stuff. This leaves the back-end just being a dumb business-logic server that has functions that return values.

Routes are only necessary in the context of a browser, and when that's handled via JS/Cljs, the JS/Cljs doesn't have any need to keep using the "route" metaphor to communicate with the backend.

my web apps mostly use just two backend rest resources for everything: one for datomic queries and one for commands

then i add other stuff as needed that doesn’t fall into those buckets

Right but REST is only necessary when interoperating with other services. When your back-end and front-end are tightly coupled, they can just use EDN, and at that point they don't even need routes.

so yeah, no transparent function calls but commands are data that end up being evaluated by function calls

yeah i guess i could reduce my two endpoints to one but shrug

i use transit instead of edn

which is probably a premature optimization

Maybe not. Depends on how much data you're passing. EDN can be lengthy.

calling them rest resources is probably inaccurate too i suppose — they’re just HTTP resources with a particular contract

Meh, nobody really means the same thing when they say REST anyway 😉

yeah, i heard that transit can leverage the native JSON parsing in the browser too

heh, true

@sdegutis: cljs-http + an endpoint that runs all POSTed edn through a defmulti has worked just fine for us

Neat idea.

the defmulti affords us all the organisation we need, because we can implement defmethods anywhere. that plus a sufficiently sophisticated dispatch value - e.g. [entity-type action], and you're golden

Love it!

And then a third argument just takes optional data?

client simply invokes the same fn for all calls, passing different data, and uses async to get results (because cljs-http uses async)

well, you're passing a map, so all the data is in the map

Right, right.

Are you using Datomic btw? I don't often see the term "Entity" used outside it.

(defmulti api (juxt :type :action)) (defmethod api [:user :add] [{:keys [email password]}] ...)

yep 🙂

I like this plan a lot.

(POST "/api" request (-> request :body util/read-edn api util/edn-response))

of course, you probably want to pass request along as well so that you can deal with session etc

and you probably want to use nicely factored transit middleware instead of this lazy threading of edn functions - but the thread shows what should happen

it's simple, immediately obvious what's going on, and it scales quite well!

yeah same idea here — commands are handled by a multimethod

i still like having liberator for error handling, ser/deser, etc.

yeah. makes sense to have that stuff in middleware

is there a mapc version of map explicitly for side effects? Or is it just best to (doall (map ... ) )

there's run!

@dpsutton: If all you need is side effects there’s doseq.

ah yes. thanks

@dpsutton

(dorun (map ... ) )

is that preferable to doall?

mapv is eager if that’s what you want

doall holds the whole seq in memory

and returns the seq

ah, yeah i guess there's no such thing as a lazy vector

thanks chris. good to know

Say, anyone know of a reasonably fast command-line tool for pretty-printing edn? And ideally terminal-coloring it as well?

I was hoping to cook up something fast in planck, but it doesn't seem to implement clojure.edn/read

you might try fipp https://github.com/brandonbloom/fipp

Oh, perfect, thanks @alexmiller!

Is ring + compojure the best stack for creating web app backends right now?

I'm trying to implement a custom data_reader, it appears to be called twice. It does (swap! atom dec) and i see the number decreasing by 2. Can anyone suggest why?

Lots of people like ring+compojure. Personally, I think any routing library that can’t provide the inverse function is incomplete. I’d reach for bidi if I were using ring nowadays, I think, and would take a long hard look at liberator.

Pedestal has a lot to offer, that’s what I’m using now fwiw

Solved it myself, apparently I have to quote the form to prevent it being evaluated twice

@donaldball: pedestal seems great! thanks for the heads up, I’ll probably work with that

getting mileage with bidi + liberator over here

@donaldball: what do you mean by the inverse function?

dpsutton: e.g. {:action “foo”} -> “/action/foo"

so you can take the data representation of a location and produce something the client can make a URL with

hey guys, does anybody know why does the nrepl outputs exceptions filenames as 'form-init<random-number>' even if the filename, line and column are set on an eval call?

In 1.9.0-alpha10, is map destructuring not going to be backwards compatible? For example, in clojure 1.9.0-alpha10:

(let [{:keys [foo/bar]
       :or   {foo/bar [1]}} {}]
  bar)
=> nil

(let [{:keys [foo/bar]
       :or   {foo/bar [1]}} {}]
  bar)
=> [1]

anyone know why this is?

(/ 100 (get {} :foo 0.0)) ;; => throws ArithmeticException
(/ 100 0.0) ;; => Infinity

ah i'm sorry i misread

why is the behavior different for the missing key entry with default? or when the key is in the map, even: (/ 100 (get {:foo 0.0} :foo)) => throws exception

np

(class (get {} :foo 0.0)) java.lang.Doubl

super strange

is there some type casting optimization that can't be done here?

in the second, analyzing the types clojure can see that 100 is an int but 0.0 is a double so do double division?

hm, (/ 100 ^double (get {:foo 0.0} :foo)) ;; => Infinity

i think you’re onto something

i did the same without the foo tag in the map and it produced infinity. seems like the runtime has already commited to integer division

does that mean this isn't a truly eager evaluation method?