This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # atom-editor (5)
- # babashka (15)
- # beginners (80)
- # calva (11)
- # cestmeetup (6)
- # chlorine-clover (15)
- # cider (22)
- # circleci (3)
- # clojure (57)
- # clojure-europe (19)
- # clojure-italy (1)
- # clojure-nl (4)
- # clojure-spec (1)
- # clojure-switzerland (1)
- # clojure-uk (88)
- # clojurescript (92)
- # code-reviews (1)
- # crux (26)
- # cursive (6)
- # data-science (5)
- # datascript (6)
- # datomic (12)
- # events (7)
- # figwheel-main (2)
- # fulcro (55)
- # graalvm (2)
- # helix (6)
- # juxt (6)
- # kaocha (11)
- # luminus (2)
- # off-topic (82)
- # pathom (27)
- # portal (1)
- # re-frame (3)
- # reitit (25)
- # remote-jobs (8)
- # sci (11)
- # shadow-cljs (29)
- # slack-help (2)
- # spacemacs (9)
- # specter (4)
- # sql (9)
- # tree-sitter (1)
- # uncomplicate (1)
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.
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
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
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.
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 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)
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
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.
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. https://github.com/whatwg/html/issues/2177 In the issue the chrome team (among others) suggest the browser fetch api instead so maybe I should check that out.
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 (https://github.com/heykieran/clj-pedestal-spa/blob/7607bb1b7a509cc80a82d8346c494a120c97601d/cljs-src/web/sse_logs/utils.cljs#L68)
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 https://github.com/heykieran/clj-pedestal-spa/blob/7607bb1b7a509cc80a82d8346c494a120c97601d/src/server/be_handler_pdstl.clj#L311 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.
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.
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
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 ....
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
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.)
But messing with client configs, bouncers & co is not as straightforward as slack/riot
just kind of awkward that all the good discussions , tips and conclusions from the past just disappear
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.
There is also https://clojurians-log.clojureverse.org/ with slack logs that go further back.
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'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!