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 ? https://developer.mozilla.org/en-US/docs/Web/API/URL/searchParams

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 https://en.wikipedia.org/wiki/Hexagonal_architecture_(software) 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)

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 😞 https://en.wikipedia.org/wiki/Server-sent_events

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?

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

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.

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

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. https://heykieran.github.io/post/using-sse-and-websockets/

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.

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 ....

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!

thank you so much @seancorfield!

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