vale moss
I am building this blog: https://blockenblog.netlify.app/ and people want to have a permalinks. Thing is that all the data I need to render the detail page I already have, the detail page is basically only different design of one post on a different URL. I can off course fetch the data for this one post again, but that sounds like a nonsense. What would be a best practice here?
vale moss
SSR state/passing data to another page
plain willow
you can use files, but for you this SSR counter example might be relevant https://github.com/MicroWebStacks/astro-examples#02_ssr-counter
for more advanced states sharing pattern, see my post here https://stackoverflow.com/questions/74784560/how-to-share-state-among-components-in-astro/74840400#74840400
vale moss
Can't get it working. I basically copy pasted code from shared.js to mine: https://github.com/vorcigernix/blockenclient/blob/master/src/lib/shared.js but the other page clearly fetch the data again
thanks for helping btw, I am completely lost in this
plain willow
oh, netlify serverless isolation, I think I have to rework my pattern examples differently for different adapters.
That was for a single continuously running node process.
are you familiar with Netlify solution for persistency ?
like maybe serialize into env vars, or use a key value db?
can you use local files ?
here the counter example working on netlify, not sure what you did wrong, it persists through some calls, but then forgets itself when I reopen the page after a while, I won't advise you to rely on that https://astro-ssr-counters.netlify.app/
vale moss
I have no idea how is netlify different from node tbh
but I don't think they have an access to the filesystem
but hey, there is a netlify channel, I'll try to ask over there
plain willow
ok, well then here is the bad news, "serverless functions are stateless by design"
which means I was unfortunately right on db and env var, even env var setting in netlify needs an api call. I don't think they have any memcache kv store, so refetching your data might be your best option, "welcome to serverless"
delicate gulch
I suspect the answer is here, over in the #netlify-archived channel: #netlify-archived message
plain willow
I suspect the answer is here, over in the <#961342596918177853> channel: https:...
we're talking about server side not client side, but thanks. Nanostore is just a wrawpper, and I did mention it in my SO link.
delicate gulch
@plain willow Understood -- should have looked further up the thread, but it was late 🙂
Actually I did think the talk was server-side, but wondered why one would want to do that, figured what was really needed was on the client.
It would be interesting to understand the problem actually being solved; and even if something on a server should be updated, couldn't that also well be done from the client, via an API call from the client who knows the needed state?
There was a memory ticking, that Astro could also build the remote actioning server API for this, and I found a reference in the doc..just read carefully here: https://docs.astro.build/en/core-concepts/endpoints/#server-endpoints-api-routes
Interested in what you guys think, and how that might solve that original problem...!
plain willow
Absolutely, there are often more than one way to do things. Client vs server, the decision is up to the website host owner. Ideally, be able to implement both and compare.
delicate gulch
@plain willow , @vale moss , Hmm - I did read back, and on the website, and think I can see how it was sounding confused -- besides my apologized too-rapid take 🙂 .
first, I suspect it would be well to understand what Netlify Functions (or Edge Functions) are -- even if Astro creates them automatically for you. They exist only at the moment of execution, with no intrinsic connection to anything else within or outside the Netlify sphere, to many advantages for what it can do, like the global edge high performance.
Then, the pattern Netlify would tell you is to use a remote-accessible database, for data stores.
in this (interesting) Blockenberg CMS design, you say people want permalinks. Permalinking implies the page can always be seen again...which might not be true if you try to reload it. CMS content (and structure also) is rife with change. So I consider that you really do need persistence of the original page data -- and in truth, the original page presentation means, or at least an (Astro) page that responds well to earlier forms of data, the simplest way to design for this, that you would always ensure.
what also-remote database might you use? I'm personally kind of partial to Fauna, which I used in the back end as a cache store for complex document data pulled from GitHub (don't ask...) for this instant of the times construction that still lives: https://combatcovid.equipment/. It is a sophisticated design having that same high global performance as Netlify, essential for what we were trying to do, and maybe could be helpful so also for this distributed CMS? It looks to continue with a pretty generously usable free plan, again as Netscape, and then per-usage rates above.
(cont'd)
But of course there are others, to be evaluated on your perception of needs, how dependably good, and secure, and last of all, distance performant, perhaps, that they really are(!). Especially for your visualized CMS.
The principle of use would be familiar, except it acts through a server(less) instance, the Function. You'd do API calls on the database, using fetches to write your page data for future use, and to retrieve it when that use comes. This should be quite affordable, as permalinks would not typically be very active. I think you should still be able to write these calls within Astro, set for SSR. I've even done it with a separate faceless component, in a proof for the range of what Nanostores ipc can do.
back on data stores for a moment, I had a very brief look, and see that Cloudflare has had a global KV store for a while. And, they have edge Workers, with Astro having an SSR integration with them. So that could be another possibility. Mongo, well, I try to get past my allergy in case they've ever improved, and they do have a 'global cloud' now, to be evaluated if you're interested. Scan shows a number of others; just take care in heated spaces!
Any of these are going to need some careful looks at many aspects, besides performance and technical, especially where the boundaries of free plan are to your intended use (budget for permalinks? or making a permalinks a request choice, rather than writing them for every page??). But these are matters am sure you're very considering on for the project, and again I'm intrigued to see where Blockenberg goes 🙂
Best to both, and on your morrow, which was for a long while mine,
Clive
vale moss
---
(cont'd)
- But of course there are others, to be evaluated on your percepti...
Thanks for an elaborate answer. I am a big fan of Fauna/Cloudflare KV when it comes to databases, but I actually have a kind-of database where the data comes from. This is a super simplified design on my app:
Only issue I actually have that all the data are fetched from IPFS in the initial query (for the main page). The only alternative that would make sense from a performance/data logic angle would be to render just the article name on the main page and fetch the details separately, but that would be really bad user experience.
So passing the very same data I already fetched for the main page to the detail page is the best option in this situation. But I understand the "functions" part - yeah, at least the data fetching part could be moved to the netlify function.
plain willow
post could be renamed "Serverless state/passing to another page"
so many options yet neither feels optimal due to the stateless aspect of functions.