Fork me on GitHub
#clojure
<
2020-10-31
>
Adrian15:10:39

Hi all! I have two stupid questions 🙂

Adrian15:10:36

I am playing around with luminus and defined the password column in the users table as TEXT

Adrian15:10:13

how do I read the value as string

Adrian15:10:28

(I am using H2 database)

Schmoho15:10:58

Not really that familiar with Luminus, but which library? clojure.java.jdbc?

Adrian15:10:50

because the library retrieves something like this: :pass #object[org.h2.jdbc.JdbcClob 0x3aa10bc8 "clob2: 'bcrypt+sha512$914ff82438d740391603a9771bf05108$12$d06f3f7a38812e86accd15a690d3b4c5b05a34c0b8549431'"

Adrian15:10:07

Thanks! It works. 🙂

Adrian16:10:53

The second stupid question would have been: how do drop and re-create the table with VARCHAR type by migrations? I didn't used it ever.

Alex Bishop18:10:03

The following worked for me in Postgres - note that h2 seems to use slightly different syntax*

;; REPL
(in-ns 'user)
(create-migration "change-author-type")

;; <timestamp>-change-author-type.up.sql
ALTER TABLE posts
      ALTER COLUMN author TYPE VARCHAR (300)

;; <timestamp>-change-author-type.down.sql
ALTER TABLE posts
      ALTER COLUMN author TYPE TEXT

;; REPL
(migrate) ; changes to VARCHAR
(rollback) ; rollsback to TEXT
*h2 syntax (untested):`ALTER TABLE tableName ALTER COLUMN columnName SET DATA TYPE dataType` Btw, I can recommend https://pragprog.com/titles/dswdcloj3/web-development-with-clojure-third-edition/ for a detailed dive into. Luminus.

Adrian19:10:09

Thank you very much!

Test This19:10:01

Can someone please recommend or comment on choice between aleph and http-kit. I have been trying to avoid asking that question. I have looked at both and both seem nice to use. But I want to know from the perspective of (1) bugs encountered; a few days ago someone mentioned about experiencing deadlocks with aleph. (2) which one is expected to be around for longer. (3) limitations such as being able to use other libraries with it, available middleware etc. (4) performance in production. Thank you.

seancorfield20:10:55

@curiouslearn Any reason to prefer either of those over Jetty?

seancorfield20:10:28

We've run both Jetty and http-kit in production. We started with Jetty but saw occasional, unexplained "thread death" exceptions, so we switched to http-kit and it was fine, but support by monitoring software (New Relic) wasn't great so we switched back to Jetty (a more recent version), and it's been rock-solid in production for years.

seancorfield20:10:57

aleph and http-kit are both special custom things and neither are as widely-used or as well maintained and well supported as Jetty. Last I saw, aleph was not being maintained and Zach was looking for someone to take it over. http-kit is in a similar situation, but slightly better maintained.

mpenet20:10:08

Jetty is very stable

mpenet20:10:31

I d say it's the safe choice right now

Test This20:10:34

I want something that is easy to use with websockets. Also, while I don't understand this well, I think something that is async would be better in terms of the server's capability in terms of number of concurrent connections it can handle on a very basic server, say a $20 per month Digital Ocean instance.

seancorfield20:10:05

You'd probably be surprised at just how performant Jetty is.

mpenet20:10:16

WS is somewhat a hack with most jetty adapters for clojure

mpenet20:10:40

Yeah I had jetty take crazy loads

Test This20:10:51

Thank you. Any pointers on which libraries to use for websocket connections with Jetty? Thank you.

seancorfield20:10:37

We're using netty directly for a WS-based app but that means a fair bit of Java interop (and heavy use of core.async). I wouldn't recommend that approach until you've got some serious production Clojure experience under your belt.

hanDerPeder18:11:16

Sorry to jump in, but why not?

seancorfield19:11:11

@U013U475882 core.async is pretty hard to use and complex on its own -- I see non-beginner Clojurians running into all sorts of issues when they're learning core.async 🙂 -- and netty with interop is also non-trivial on its own. So then you're combining two non-trivial things with asynchronous behavior. It's a lot of stuff to learn and get working, if you're also still struggling with a bunch of Clojure basics.

hanDerPeder20:11:35

aha, I see thanks. can confirm the ‘all sorts of issues with core.async’ part 🙂

mpenet20:10:00

For ws not sure, we used erlang for that

mpenet20:10:52

Netty is quite complex, it's easy to make mistakes if you don't know it well

Test This20:10:58

Yes, I would like to avoid that (using netty directly or erlang). But I need websockets for sure.

Test This20:10:03

What is the option then?

mpenet20:10:24

Vertx is a decent solution probably

Test This20:10:25

That is mainly the reason I was drawn to aleph and http-kit.

mpenet20:10:45

It's essentially a thin wrapper over netty

Test This20:10:14

@mpenet would you recommend VertX over http-kit and aleph. Thank you.

borkdude20:10:21

Both the client and server from http-kit are also available in babashka.

mpenet20:10:41

Just for ws yes

mpenet20:10:59

Otherwise give a try to jetty

seancorfield20:10:29

@curiouslearn What is your web socket client? JS and http://Socket.IO, or some custom ClojureScript thing?

Test This20:10:48

Standard JS. I am using Svelte on client side.

borkdude20:10:13

Btw, we're using yada + aleph at work and it's been very stable for us

borkdude20:10:21

We're using websockets as well

Test This20:10:51

Thank you @borkdude. Did you experience any deadlocks with aleph?

Test This20:10:13

Or other bugs

borkdude20:10:14

I can't say that I have. There is a common issue that when you don't consume an inputstream on error, this can cause resource problems, but I believe this is documented somewhere

Test This20:10:17

I see that it is still in alpha. Do you know anything about whether it will continue to be developed?

borkdude20:10:28

I don't know

Test This20:10:41

Okay thanks!

borkdude20:10:04

I believe it was funded with Clojurists Together money at some point not long ago

danielcompton20:10:24

Yeah in 2019 IIRC. It’s a pretty advanced codebase and needs understanding of Netty as well.

borkdude20:10:53

It's a shame that some popular projects like http-kit or aleph lean on one or two maintainers and when they change jobs the project is pretty much stalled? But I guess that's how open source software in a smaller ecosystem works...

danielcompton20:10:24

Yeah in 2019 IIRC. It’s a pretty advanced codebase and needs understanding of Netty as well.

seancorfield20:10:26

@hiredman Did we look at Aleph before starting down our own path with Netty/interop? Or did we just go straight to netty-socketio because that was a requirement imposed by our client's needs? I think the latter, but I can't remember how much exposure you've had to Aleph?

nivekuil20:10:26

Ztellman does seems to intend to ship a 1.0 of aleph as of last week, so the alpha label is probably oversold https://github.com/aleph-io/manifold/issues/187#issuecomment-716048610

hiredman20:10:52

Straight to http://netty-socket.io, I haven't used aleph

seancorfield20:10:41

Given how many Contrib libs used to be 0.x.y or have alpha labels, that aspect would not worry me much in the Clojure ecosystem. Contrib was all moved to 1.0.0 releases purely to address perception, not because of any functionality or stability issues.

borkdude20:10:59

I did recently come across a contrib lib that wasn't 1.0.0

seancorfield20:10:36

Well, t.d.a. is 0.x.y but it's definitely alpha.

seancorfield20:10:18

And clojure.java.jdbc is stable (no longer maintained) so that's 0.7.x (next.jdbc is the 1.0.0 that c.j.j never got)

seancorfield20:10:15

Yeah, that maintainer hasn't cleared a 1.0.0 release yet. I think Alex was talking to him about it.

seancorfield20:10:43

Herwig hasn't updated data.xml in a year and a half at this point tho'... 😞

lukasz20:10:52

Different approach: why not use something like http://pusher.com and let someone else handle the hard parts?

Test This20:10:37

Thanks everyone. Really appreciate all replies. Pusher is expensive for something that has revenue less than $500 per year :)

lukasz20:10:59

We've been riding the free tier for a long time. It's quite generous (unless it changed recently)

lukasz20:10:15

and there are alternatives, which compete with pusher on pricing, with the same feature set

Test This20:10:47

I think they have 100 concurrent connections limit for the free tier.

lukasz21:10:25

Depending on your architecture and the application, that's technically 100 concurrent users

lukasz21:10:31

https://www.pubnub.com/pricing/ gives you 2x that for free and has friendlier pricing. I have never used them though