Cache whole route
Closed this issue · 4 comments
For SEO, it's always a good idea if we respond to them as quick as possible, to do that one way is to optimize the production build so it responds as quick as possible, but nevertheless it'll take quite a lot of time to fully render on server.
There are multiple possibilities for this feature.
First, by default bots don't come in with cookie or anything and no matter when they come, it's always going to be similar content, so we can cache each page for few hours.
Second, if a user comes in and isn't logged in, there's a good chance in most projects they see the same thing, we can cache this as well.
The thing I'm thinking of is have a cache layer (obviously using a interface so we can change underlying tech), whatever we generate for current request, we save the data to redis/couchbase/memcached or anything, next time request comes in, if it's a hit, we serve from cache, else we simply continue the normal request pipeline.
We need to be able to define the cache key:
request_path will be initial one, and we could add whatever is a new request, OR we can have a cache handler for each request, so they can decide what duration cache should live, and what will trigger a new request (eg: if for same page, two outcomes might be possible when we have a/b testing), so we cache both sides.
Implementing this will give possibility for responding within 100ms even for a more complex page, and search engines like pages which responds quick.
I'll try to send a pr over next weekend if we agree on caching tech, I like couchbase it's simple key-value we can use by default but open for suggestions
I'll try to send a pr over next weekend if we agree on caching tech
I guess that was a very long weekend :) I'm fine with couchbase.
forgot completely,
maybe when I'm using ts-react-boilerplate next time 😄 I'll try to get some free time, it's been very busy year.
I evolved, and I don't think this should be the case anymore, hear me out.
Your API layer needs caching, not the rendering, React is fast, and rendering is really fast as well,
As long as we use tinka client correctly with a mock middleware, the rendering should be really fast, and if we need more scalability, the whole point writing stateless apps is that you can just deploy it to one more node, there's no reason for whole html to be cached.
Rather write API calls correctly, use tinka's Cache layer (it's not good right now, so we'll have to write a better CacheMiddleware for it, nevertheless caching belongs there), that way we scale better, and even if we want to change UI even for non logged in user with best performance, we'll be able to.
Haha you evolved. Awesome.