Hi all, I'm new to clojure and want to use reframe/rum for a mid-side web app. what are the various solutions to SSR for reframe? so far, I've come across https://github.com/pupeno/prerenderer
The answer is not as straightforward. I'd suggest searching this channel for SSR and reading a few of the most recent threads on the topic.
The result didn't yield a definitive answer. I guess I'll look for a work-around
@olajeremy123 when you say mid-side, do you mean "server-side"? If not, what is a mid-side web app?
oh, it was a typo 😅. I meant "mid-size". as in not a large site. I just need basic rendering on some pages for SEO, while main features can be a full SPA.
> can be a full SPA But do they need to? Plenty of people are happy with non-SPA apps when they're made properly. There's also a middle-ground of sorts when you use AJAX requests to fetch HTML fragments instead of data that drives HTML changes. You can search for "htmx" here to get a whole bunch of links and discussions on the topic (doesn't mean you have to use htmx, but discussions about it usually yield alternatives as well).
For what I'm building, it doesn't have to. I just want to do something with reframe
Why does SSR make rendering for some pages for SEO easier? You don't want to have to pre-ship some js artifact for a one-off page? Or do you want to be able to change it fast, without changing a deployed artifact?
Or is it just cause some spiders can't crawl SPAs as easily?
I actually like the idea of "mid-side" rendering 😆
Something in between SSR and SPA, where you ship widgets as an IR built in clojure data, at a minimum level of definition needed to express the domain of your app. So the front end is still converting the cljs data to js at runtime, but that data is driven by the backend. Have your frontend cake and eat the backend cake too
hmm.. it was my thinking that search engines rank non-SPAs higher, but after few mins of research, it looks like both bing and google can crawl js sites without any issue
I'm still a tiny bit worries about lesser known crawlers
Yeah, and there's tools/fixes for where they can't very easily
what tools/fixes? kindly elaborate
I'm not an expert on that specific thing, but there's google tutorials on how to make your spa seo friendly
Things like doing navigation right
with history
ohk, would look them up. thanks
and pre-sharing a site map for the spider
btw, ur "mid-side" idea sound interesting. too complex tho
Mid side is the future!
just sync your front end db to your backend db
let your clients do your work for you and just spec the data moving between your clients
And then you can drive things from the backend by just updating shared tables/data structures
But why pay AWS for what your front ends could be doing? You've got a supercomputer sitting in the collective pockets of your users. It's wild how much they're not yet being used IMO
That's what this new InstantDB is doing for you, right? Just syncing a db between your clients
Like crdts but without the hassle - your backend is just the hub. Your frontend updates are versioned and your backend just spec checks changes between clients and frontends rollback on conflict
I built a thing that does the thing - I just haven't open sourced it yet. But it's trivially easy to build. Just use a diff tool like editscript to scrape minimal diffs off your fe-db changes, send those as updates to a backend data structure that gets spec checked. The history of the app is versioned so you can time travel debug the whole thing from the synced version of the db on the backend. And then let the backend force client side updates. It's very easy to build.
Actually, here's a cljs version that's already public: https://github.com/johnmn3/todosync/blob/main/src/server/todosync/server.cljs#L180
That's a super minimal reference impl. Not much of a rollback strategy impl'd yet iirc
Going back to your original question - rum works in Clojure (in addition to ClojureScript) specifically to support SSR, so I would not expect much of an issue there.
As long as you know what app-db should look like for your first render, at least, calling the top-level rum component of your app in your server-side code should be pretty much identical to the same call in your client code.