That's cool and definitely the future of HTML streaming,
it simplifies things a lot: js enabled out-of-order streaming leads to SEO problems and frameworks usually need to come up with workarounds - detect bots and turn of streaming for that case.
With such technique no workaround is needed, less things to worry about.
I also wrote a bit below: "be transparent to components and not affect their logic in any way (make components think they communicate to Backend directly)"
I met people trying to use ReactQuery with the mindset that it's a Store. The result was that they were greatly frustrated with the outcome. That mindset led them to use ReactQuery in a way it's not supposed to be used. Every now and then they wanted to directly manipulate with the Cache (the "Store" underneath ReactQuery).
That's why I find that Store-mindset very dangerous when working with such Libraries.
Better come with a mindset that there is no Store at all. Better think that "useBookQuery" is just a simple hook to fetch data. NO STORE.
>To me, “directly communicating with the backend” implies that I have to have REST calls in my components, and handle all that comes with that
This is exactly what I meant :)
I'm glad that you found the article useful. Thanks again for providing your feedback!
Very good question about the difference between `getFromStore` and `useBookQuery`.
When using `getFromStore` you have the expectation that the value is already in the Store. Someone should have already put the value there somehow.
You have also the expectation that `getFromStore` is synchronous and simply gives you nothing if the value is not there.
With `useBookQuery` you expect the value to be fetched from Server. There is no 3rd party to care about putting the value in the Store. `useBookQuery` is simply like `fetch('...')` from a Component perspective.
With libs like ReactQuery every component "simply" fetches what it needs, sort of directly communicating to the Backend. No intermediary party (like a Store)
>React is doing a lot of work with Suspense ...
Yeah, I heard about React team collaboration with libs like ReactQuery on making Suspense work with those, also on server side. But I'm not much into that Suspense topic, so decided to not mention anything about it.
>I suggest emphasizing the loading/error mechanics more strongly at the end of the article.
>the quality and intent Marin fowler’s of writing is actually respectable.
Sorry, didn't want to be picky, but the article you mentioned is not written by MarTin Fowler. And I also didn't find there many "citations" you were looking for in my article.
I'm sorry that you found my article of a little quality.
I did my best trying to analyze different approaches to Data Management, How we came to those and their problems. I illustrated those with the my own diagrams to help readers better understand the concepts.
The article is based on my 10+ years experience in the industry.
It went through many iterations of reviews and corrections.
There nothing unique in the approach I described. It builds on what libraries like ReactQuery allows to do.
I basically just tried to formalise why I see this approach as the next logical step in how we approach building UI apps.
I'm not a native English speaker and not a professional blogger. Most probably there are ways to write such an article better. I do my best learning how write better.
Having said that, I think you are not fair comparing it with your "expert-junior-evangelical" phase.
>Let's say you want to add a button somewhere that hides/shows another widget.
That's a good case. This is purely UI state, right? (we don't store it on the server).
For UI state we still need to depend on prop-drilling or State Management solutions.
In the article I'm mainly talking about the Data which exist on Backend (as you can also see from all the pictures). In my experience such Server data is 90-95% of all data in most UI applications and that data contributes the most to the complexity.
Pure UI state is often just a fraction of the the whole State and is's often synchronous, so managing it should not be complex. So this kind of coupling will still exist.
To clarify, I do not say Widgets should be 100% independent. We do not achieve complete decoupling. But moving Server Data under control of Widgets gives us closer to this.
With pure Redux approach the mutation flow is more complex:
- send mutation request to Backend
- fetch updated data
- put the updated data in the Store
- see the updated data propagated in components
The suggested approach:
- send mutation request to Backend
- see the updated data being fetched and displayed by components
To me the second is much cleaner and easier to reason about
If there is no cached data, then it doesn't matter.
With Vercel it doesn't matter even in case there is valid cached data, because Vercel doesn't execute the function in that case.
Cloudflare always executes the Function regardless of the existence of cache and it's Function's responsibility to respond with Cached data. Hence, distributed Cloudflare functions is a necessity.
if it's a real issue and you have to issue lots of subrequests, then you don't really get advantage from all Cloudflare micro-optimisations.
In such situation I would suggest to look for other Serverless providers, or maybe traditional approach works better in such case
Serverless are not all the same.
Cloudflare uses V8 and you can't require npm packages, right.
Vercel and many other implementations use NodeJS and you Can require npm packages.
Thanks for feedback!
Caching... it took me time to get my head around it. With Vercel it works more or less the way I imagined. It surprised me that Cloudflare has a different approach. But once I got it, it started making sense and I like it :)
> in what situation is it really worth all the added complexity of risk of pushing out functions to the edge
If you are talking about developer point of view, then there is no additional complexity. All the complexity is covered by the underlying platform
> what is the advantage of saving a few ms on a transaction?
one example - if a transaction consists of a few separate sequential transactions, then ms add up and might affect user experience.
Also an app might need to issue lots of requests on a page load and taken that there is a limit on parallel requests (6 requests per domain), the advantage might be sensible.
Having said that, I tend to agree that many use cases are not sensible to a few ms advantage
it simplifies things a lot: js enabled out-of-order streaming leads to SEO problems and frameworks usually need to come up with workarounds - detect bots and turn of streaming for that case.
With such technique no workaround is needed, less things to worry about.
Excellent!