Can a service worker even cache them in the same way?
I'm guessing everything goes though the Service Worker, so yes? But I'm no SW expert, I only really know them via scripts that come bundled with 'create app' toolkits, & via Cloudflare Workers.
What I mean is if you are streaming back a response with specific data from the server dynamically the value of service worker caching goes down. Like if you start combining your data with your static page, the static part is no longer cacheable in the same way. I think people who serve dynamic pages are used to this. But I wonder if we hit state where initial render and cached response needs to resolve data in a completely different way. So if the routing is happening on the server and it's keeping track of your state it needs to know what data has been fetched before what data is stale etc. I've come accustomed to client side caches keeping track of that. The client outliving the life cycle of any individual request. If both sides are keeping track they need to communicate that information back and forth. If you go to a page and then navigate right back to it maybe you don't need to load the data again. Maybe you don't even need to load the html again (if it is server rendered). There are a lot of nuances here when you are on both sides. It's lot easier to have a clear responsibility. I suppose service worker specific modules could handle those details and abstract them from the client but a lot of complexity there.
I started programming in 1995 with Microsoft BASIC on MS-DOS from a book I found in my father's library, and I slowly (having no real mentors) learned other programming languages by myself.
What if there was no state management in the backend, and everything moved to the frontend? Sort of like a backend in the frontend. And the actual backend just streams modules of code, compiled or not, as needed by the frontend as soon as the frontend hits calls into those modules; or it streams preemptively in the background for "adjacent" modules?
And when you need something else besides frontend code, like actual data to display, I guess just go the normal way, like we do it now: hit an API endpoint but use some client-side caching mechanism (possibly with local persistance) like SWR or react-query.
Of course, for low power devices, SSR might still be needed... so maybe a solution would be having a mirrored frontend context in the backend, including all frontend platform features (like those that should be provided by a browser). So like having to delegate everything but the presentation layer (the actual UI rendering), to the backend.
This might have security issues that can't be tackled... I'm not sure, but I can't think of a better way.
I'm guessing everything goes though the Service Worker, so yes? But I'm no SW expert, I only really know them via scripts that come bundled with 'create app' toolkits, & via Cloudflare Workers.
github.com/tomByrer/awesome-cloudf...
What I mean is if you are streaming back a response with specific data from the server dynamically the value of service worker caching goes down. Like if you start combining your data with your static page, the static part is no longer cacheable in the same way. I think people who serve dynamic pages are used to this. But I wonder if we hit state where initial render and cached response needs to resolve data in a completely different way. So if the routing is happening on the server and it's keeping track of your state it needs to know what data has been fetched before what data is stale etc. I've come accustomed to client side caches keeping track of that. The client outliving the life cycle of any individual request. If both sides are keeping track they need to communicate that information back and forth. If you go to a page and then navigate right back to it maybe you don't need to load the data again. Maybe you don't even need to load the html again (if it is server rendered). There are a lot of nuances here when you are on both sides. It's lot easier to have a clear responsibility. I suppose service worker specific modules could handle those details and abstract them from the client but a lot of complexity there.
What if there was no state management in the backend, and everything moved to the frontend? Sort of like a backend in the frontend. And the actual backend just streams modules of code, compiled or not, as needed by the frontend as soon as the frontend hits calls into those modules; or it streams preemptively in the background for "adjacent" modules?
And when you need something else besides frontend code, like actual data to display, I guess just go the normal way, like we do it now: hit an API endpoint but use some client-side caching mechanism (possibly with local persistance) like SWR or react-query.
Of course, for low power devices, SSR might still be needed... so maybe a solution would be having a mirrored frontend context in the backend, including all frontend platform features (like those that should be provided by a browser). So like having to delegate everything but the presentation layer (the actual UI rendering), to the backend.
This might have security issues that can't be tackled... I'm not sure, but I can't think of a better way.
You might be interested in CloudFlare Workers to pre-render the content:
github.com/tomByrer/awesome-cloudf...
Definitely interested in this, serving from the edge seems really interesting.