This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-04-07
Channels
- # babashka (31)
- # babashka-sci-dev (10)
- # beginners (64)
- # biff (11)
- # clerk (5)
- # cljdoc (2)
- # clojure (84)
- # clojure-boston (3)
- # clojure-conj (2)
- # clojure-europe (11)
- # data-science (19)
- # datomic (118)
- # fulcro (3)
- # graalvm (3)
- # hoplon (6)
- # inf-clojure (146)
- # instaparse (5)
- # lsp (13)
- # malli (3)
- # off-topic (13)
- # pedestal (5)
- # proletarian (5)
- # re-frame (14)
- # reitit (12)
- # releases (1)
- # ring (19)
- # scittle (2)
- # shadow-cljs (155)
- # slack-help (3)
I want to create a websocket client serverside (to get data from a third party)… should I leverage what Biff uses for its magic, or bring in my own deps?
hmm, biff doesn't include anything for doing a web socket client on the server, so you'd better bring in something
Being super lazy here, so feel free to ignore (because I could just try it and learn the steps): I want to build my million toy projects off one domain in DO… should I reflect that intent when answering Enter main namespace (e.g. com.example):
or in any of the other entries? Any changes in the config files? Any tips on the DO configuration? I should mention the obvious… it’s subdomains I’m after (or a similar strategy). It’s all born out of a desire to create more ‘utility apps’ much like microservices… which perhaps suggests I shouldn’t be using Biff for them, but you never know when you’ll want the Biffy goodness.
The only thing that really matters for subdomains is the :biff.tasks/server
config option, and the value you enter when you're deploying for the first time and certbot asks for the domain.
You can also use the subdomains for the namespace, e.g. com.example.foo for one project, com.example.bar for another etc. That's what I would do, but it's not required or anything
By creating more small apps that rely on each other I can avoid bloat and also encourage reusability, I’m thinking, as well as stay focuses on the core functionality of each. CORS issues in local dev may be an unwanted result (which I’ve never really mastered avoiding).
But then again, CORS hell is largely avoided with Biff.
yeah, CORS comes up more when you're doing SPAs. it would come up if you're making a request from the frontend to a backend service that isn't on the same domain. with biff, even if you're having different biff apps call each other, the request is probably being issued on the backend, so CORS wouldn't take effect. However if you wanted to have htmx call an endpoint from another biff app, then you'll need CORS. it's not that hard to set up in any case; just toss this in your middleware: https://github.com/r0man/ring-cors
I think I recall there being possible tangles around ssl certs and subdomains and that relates to project setup.
I found this, but may be a bit orthogonal to my question (but it does sound cool). https://github.com/jacobobryant/biff/issues/58