> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.
Not necessarily. I think you're conflating caching/fetching and rendering here. You can cache rendered views in the same way you'd cache the data for those views.
Turbo does this, for example. When you navigate to a cached page it will display the page from the cache first, then make a request to update the cache in the background. So it's similar to what you describe, but with server-rendered content.
Sort of. There's been no shortage of vulnerabilities where user data has been exposed when an authenticated users request was cached and re-used for subsequent users. It's been my experience that most SSR apps disable caching for authenticated users, or rely on more explicit control of components for partial caching where possible.
> so it breaks the pure function assumption right there
There's no pure function assumption being broken here. React is a framework for rendering UI from state and coordinating updates to that state. That's why we have things like `useEffect`, contexts, and so on. The only part of React that is expected to be free of side effects is rendering.
Put another way, given your example, React just says that you shouldn't issue your Ajax call in your rendering code. Instead, you should do it in response to an appropriate action, such as a change event on your form controls.
You can find the difference between dates by subtracting one from the other, the same way you’d find the difference between two numbers. That’s why there’s no need for a function to do it.
> It feels like a lot of these freelancing micro-entrepreneurship perspectives sort of ignore this aspect. It's hard to imagine people still doing it when they're 50.
Why do you say that? I’m asking this genuinely, as someone who is a) dipping my toe into freelancing and micro-entrepreneurship, and b) turning 50 next month :)
Personally I’m just looking for a way to find more enjoyment and meaning in my work, and to be able to balance my priorities in life a bit differently. Which is something I didn’t think much about when I was younger, but has come to be important to me as I get older. So to me, this sort of age actually seems like a natural time to want this approach.
If nothing else, you eventually reach a state of seniority where the types of freelance work available that require the knowledge you have by 50 are quite a bit fewer than the number of 50 year-olds in the world, given that is still well below an average human lifespan. So it may work quite well for you, but it can't work for an entire economy. If everyone tried, most would fail, even if they all had identical skills and knowledge.
Note k__2's actual answer ended up being technical writing and developer relations. There is always going to less demand for developer relations than for actual developers. So if you say a career path should be something like be a FTE salaried developer from 20 to 30, and then "graduate" or whatever to freelance developer, then to developer relations, that's fine as long as you're in the smaller tier of people who can do that, given the world is going to have roughly the same number of 50 year-olds as 25 year-olds in an OECD nation.
The reason this hasn't been a problem yet in software is software itself is still an immature industry, so rapid growth has meant there are always a lot more 25 year-old developers than 50 year-old developers. That won't stay true forever. As the industry matures and reaches a stable size, more senior people are either going to need to stay code monkeys or we're going to see severe organizational rot with an inverted pyramid org structure with more managers and architects and developer relations specialists than developers. That will be true whether or not the organization is a single company or thousands of individual contractors.
I found usually they'd be on the order of a few hundred milliseconds. They tend to be quicker if you have more memory allocated to your function (because the additional CPU power helps).
I've mostly found that my cold starts were slow enough to look bad in the metrics, but fast enough (and rare enough) that the impact on user experience wasn't actually that noticeable. Given the other benefits I was getting from Lambda (like the easy scaling and low maintenance), it was worth the occasional small blip in latency.
And for functions that aren't directly user facing -- like processing items from a queue -- I've not found it to be an issue at all.
Of course every use case is different though, and some apps can tolerate this more than others.
What I've started doing (and how I cover it in the book) is using the CDK to build and deploy the Lambda code. The `GoFunction`[0] construct handles building and deploying the code, so you don't have to set anything up manually.
Underneath it still happens by way of S3 & CloudFormation, but the CDK abstracts away a lot of the details, which makes it quite convenient to use.
Thanks! And that's a good point about EFS, it's something I've found very useful too. I'm planning to add some updates to the book, so I'll put it on my list of things to include.
Not necessarily. I think you're conflating caching/fetching and rendering here. You can cache rendered views in the same way you'd cache the data for those views.
Turbo does this, for example. When you navigate to a cached page it will display the page from the cache first, then make a request to update the cache in the background. So it's similar to what you describe, but with server-rendered content.