Fork me on GitHub

Is there a term for both the path parameters and query string? I'm refering to them as search parameters but i cant tell if im missing a more common term.


URL parameters?


that seems to refer to the same group as the query string.


idiomatically I've heard "params", but that's super generic - ring wrap-params can merge query params and request body, to me "search parameters" are the query string and the other thing is request body - maybe I'm misusing the terms? or do you mean the way an individual router decides to interpret a path as if it were parameters (rather than specific reified locations which is the default)?


I call those "router params" because they are a black box to clients, with no reification in the protocol itself


I'm writing a post about interpenetrating urls and it occurred to me that i had never seen a single name for both query params and path params. That their isn't a common name makes the post more interesting. Yea. search paramaters has also been used to refer to both and url params has been used to refer to just the query string. So either I retake a term or we come up with a synthetic name.


I think that usage of "search params" is non standard, and in libs that offer something called search-params it's just the part after the ?


I could be ignorant though! happy to be corrected


No, your right. There isn't a term then. query, search, url have all been used to refer to the k=v part.


on the side of opinion / design, I choose to make a hard distinction between what's part of the REST interface to the outside world, and what's internal logic of a site implementation


so I feel a little uneasy just jumbling them in one pile, outside of the logic of a specific namespace internal - to me the even handlers for routes shouldn't have any concept of router params (and should have a uniform interface to access their own route if needed, not a programmatic transformation reified into the codebase). Any code that wants to access the structure of routing should be using a function in the ns holding the router itself (perhaps provided via middleware) to answer all questions about routes and locations.


this is derived from the experience of implementing customer facing pages, and needs of stakeholders in marketing or client representatives to rename or relocate for aesthetic reasons


but even with internal tools that are not market driven, I have seen the pain of moving / maintaining route logic that leaked into the entire codebase... it's unpleasant


hahaha sorry to totally off-topic your off-topic


It's definatantly on topic.


haha hope I'm not trying to ghost write your blog post then :D


I'm not familiar with "interpenetrating urls" - is this a metaphor?


A typo. I meant to write "interpreting urls"


haha nerd snipe of a typo, imagining what that would be was taking me places


I'm wrting about viewing the process of parsing the path and query parameters to executable code as similar process to what a compiler does. The goal is mostly to encourage people (myself included) to think carefully about the language of the system (in this context) and its limitations.


I'd be fascinated to read the article when it's done


As an example. Writing a grammar to output a query where path and query parameters are treated the same is very easy. Adding the idea that the query parameters applies to the last path parameter (a common pattern). Is significantly more work. Likely my first attempt has bugs. The question's we should ask ourselves are along the lines of "what are the limitations to the language were using and are they acceptable for our goals". On the tail end i hope to do some work comparing the traditional (as yet unamed) path and query paramters against graphql and pathom. Basically, i want people with language design theory to weight in because i feel like half the web runs on one off client server rest languages.


if it's not overboard, this might help as a model of the boundaries I find it super useful and very compatible with everything we use in mainstream clojure


I'll take a read. thats been linked before and i havent' had time.


tl;dr a more nuanced alternative to layers


I should go to sleep before i catch my second wind πŸ™‚. Thanks noisesmith your input is always appreciated. I'll hopefully have a rough draft done in a day or two. Possible a mini library that provides an example.


after being reminded of the "language of the system" talk in the convo above, I've decided what to put in my "hold-my-beer" library (I came up with the name first, but this is the perfect thing to give that name) - it will take a protocol plus at least two implementations, and at runtime randomly provide the impl out of the set available; a circuit breaker for bad designs (anything that relies on details outside the interface will just break - and break early)

notbad 1
πŸ’― 2

darwinism for app architecture :D


Can anyone recommend a streaming protocol for public facing web applications (the clients are both browsers and native mobile clients)?


I don't have high performance requirements, but I would like simple authentication functionality, and a robust streaming experience for the client.


The data that's being streamed is just json (streams of events) in decently small chunks (a few bytes to 2mb max).


Server Sent Events is an HTTP extension built in browsers and simple to support in servers. It’s an old tech (older than websockets) but bafflingly is not supported in IE11 😞


Yeah, I've played around with SSE a bit and I like it.


I think it covers many of my cases, but I have a few where the client needs to stream up to the server as well.


Do you know how authorization works with the event source api?

Kieran Owens12:08:34

SSE uses standard HTTP auth mechanisms, nothing particularly different between opening an SSE endpoint and a standard HTTP endpoint.


I did some googling and found the EventSource browser API, but there's no way to place authentication headers there. My guess is it works fine with cookies tho. In the issue the chrome team (among others) suggest the browser fetch api instead so maybe I should check that out.

Kieran Owens11:08:56

True. But you can encode most of what you need in the URL and have the server check whether the connection can be opened. It's a one-to-one approach rather than a one-to-many approach (which SSE doesn't handle I believe). The approach that worked for me is here (

Kieran Owens11:08:42

It encodes the user, the connection and the stream in the URL, and the server decides whether it's good to go or not. Using pedestal route here and


If you want client streaming to the server SSE is not suitable, it only handles server streaming to client. Websocket is bidirectional, but you need to add logic for reconnection etc. SSE uses plain HTTP auth, websocket starts with HTTP auth but I’m not sure if you need something extra after that.

Kieran Owens12:08:17

curl can simulate SSE, although you'll get a bunch of blank lines (due to the keep-alive process, I think)

Kieran Owens12:08:56

If it's at all helpful, I put together a blog post on webscockets/sse for sending message from a server to a client. The post is focused on websockets, but the attached repo also demonstrates sse (I haven't had the time to add the sse blog post, ya know, work). It covers authentication and security as well.

πŸ‘ 1

I found that the websocket stuff wasn't super hard using sente, though the lib ecosystem sente is built on can be weird. Can't rule out that this was just a question of using it slightly wrong.


I started out using SSE with yada / aleph. It's pretty much built-in. But later on we had to move to websockets. It was only a tiny change.


Now I built my own fallback model which starts with websockets, then falls back on SSE and then polling. Very simple code. No libraries.


it's funny how you're considered a rebel and almost savage these days if you don't pull in mountains of libraries for one mere feature


that's good to hear, maybe I'd just use websockets directly next time then


if we only had a good programming language at hand to write a slack clone that would run on the web and rely on some cheap ass storage so we could have chat history forever and not be greeted with the annoying slack warnings every time we open clojurians ....

Vincent Cantin16:08:40

there is zulip as well

πŸ’― 1

network effects are a hard problem, best solved by marketers not engineers maybe


not sure i agree there


skype did very well on communications front before the experts arrived


and can't really claim experts improved anything, it seemed all went downhill from there


yeah, I'm just convinced the hard parts are not technical (there's no reason we couldn't use matrix or whatever right now, they work fine - even IRC still works), they are behavioral


we use slack because we know it and other people are there, we know it and other people are there because it's a sunk cost - we had to figure it out for work, we had to figure it out for work because their team was good at selling it to employers


better platforms than slack already exist, it isn't an engineering problem


It was good enough at the right time. Things are different now but moving away from it is not frictionless,even with bridges


my argument is that "good enough" isn't a fixed function, but one that's recursive and depends on social consensus, it's not a technical problem


(That said matrix/riot solves most of slack problems, probably introducing others but at least it's more open.)


I'm also happy on IRC


Same we use irc at work, it just works


But messing with client configs, bouncers & co is not as straightforward as slack/riot


well i wouldn't mind to have searchable history and not losing my dm-s here 😞


just kind of awkward that all the good discussions , tips and conclusions from the past just disappear


but we can't really afford the paid version of slack for the community


their pricing is not designed for this


we use the paid version of slack at work, and there it makes perfect sense. good integrations with our toolkits, easy to use.


Clojurians Zulipchat records most of the public conversations from Slack in a searchable manner with history going back to about beginning of 2019. It does not archive private Clojurians Slack messages.


thanks for the link


There is also with slack logs that go further back.


i have found both to be useful


at the austin conj a few years ago i met a really nice guy who was a dba and had actually worked on the postgres source itself. Might anyone recognize someone based on this description? Interested in talking about some postgres contract work.


he also was a clojure guy (besides just randomly being there) is why i ask πŸ™‚


@dpsutton I think I know who you mean... Michael Glaesemann maybe... aka @grzm ?


He's certainly very PostgreSQL-savvy and has worked with the innards of the drivers, as I recall...


oh i think you're right! and didn't know that was @grzm who i've interacted with here and never connected the two!


@dpsutton He's helped me out with some PG-specific stuff around next.jdbc...

πŸ’― 1