(doall (map connect servers))

It's a little unintuitive that connected? and disconnected? aren't negations of each other.

I don't see any coordination for writing to a connection. This could cause interleaved writes in a multi-threaded context (which may or may not be a problem for your use case). One option might be to use a java.util.concurrent.ConcurrentLinkedQueue or similar.

Generally speaking, there are few operations that could be run from any thread. I might consider something like having a queue for each connection that make sure operations like disconnecting, joining, logins, etc aren't interleaved.

Personally, I reach for core.async for this kind of thing, but it's not everyone's cup of tea.

join-all-channels returns a lazy sequence. I would prefer doseq over for in this context.

connect initializes the connection with the :channels key from server , but doesn't otherwise join a channel or deal with channels. I would probably have connect ignore :channels from server and include that info in conn elsewhere (like join)

Hey Adrian, I appreciate you responses, I am completely new to programming, I ask that you forgive me but what could go wrong in this case of uncordinated writes to the Socket’s output stream. I haven’t fully wrapped my head around a lot of the Java classes that I am using in this code.

The way connect currently works feels awkward and I am not sure if I am modelling things correctly. Good call on connect? & disconnect these are experimental and I have noticed odd behaviour with connected? returning through even though the socket is closed.

This is my first project in Clojure and my aim is to learn how to model problems, as a professional engineer would. So any feedback towards that would be greatly appreciated.

> what could go wrong in this case of uncordinated writes to the Socket’s output stream. for (.println (str msg "\r")) , it basically means that it would be possible for multiple different messages to be written with characters interleaved: part of one message, followed by part of another, followed by part of another, etc. In some cases, it might be unlikely for short messages to be interleaved, but I find that it's usually best not to rely on implementation details.

IF Each OutputStream is on a dedicated thread. Would this still be an issue?

yea, that should work.

It seems like creating a duplicate slug should return an error if it randomly chooses a slug that already exists, https://github.com/rmrt1n/urlfrog/blob/82c86db1ee5b6043ddaa5f36fd29a7e02a36a32a/src/urlfrog/routes/shorten.clj#L27

It doesn't seem like there's a uniqueness constraint on slug ids for your xt db.

The logic for creating a slug is coupled to the request handler. I recommend having a standalone function for dealing with slugs.

I see, thanks!

some style and factoring ideas for shorten.clj