search

mjackson / remix-the-web

Open source tools for Remix (or any framework!)
MIT License
665 stars 13 forks source link

[headers] Add the "304" headers (ETag and friends) #21

Open skabbes opened 2 days ago

skabbes commented 2 days ago

Context I currently don't use any remix-the-web libraries, but after hearing about them on the remix roadmap planning, I am evaluating the headers lib. I realized that it didn't have the all the headers I needed.

I am building a little remix app that syncs from arbitrary iCalendar feeds. In order to be a good citizen of the web (and save my own bandwidth), I would like to send conditional requests to the upstream servers with If-None-Match (if the previous response had an ETag), and an If-Modified-Since (if the previous response had a LastModified).

Additionally, I'd like to respect the upstream server's cache-control headers as well, but I think everything I need is already here.

Request Add headers to this library for:

I'm happy to help on this, but no ego about doing it myself (if think this is a good idea, @mjackson just go for it).

Discussion New remix-the-web package?? Cache + Cookies?

In addition to these changes in the headers library, there might be an opportunity here for a server-side Cache. I could see this being a common building block of "I want to make requests on a server, but doing all the "normal" stuff that a Browser would do out of the box (in terms of caching, cookies, etc)".

I see this as being a "Cookie Jar" + "Cache implementation", and integrated into fetch somehow (I can tell fetch us use this context for a fetch). Similar to the file-storage package, this would probably need pluggable persistence. In my use case, I'd need this to be durable in Redis / DB / etc.

sergiodxa commented 1 day ago

Regarding Cache, I built a POC some years ago, and tried it, but it's too limited IMO to use it server-side.

If you're only fetching an API it may be great since you cache the response associated to a request, but if you query your DB, or even use an API but through a SDK (Like Octokit) then you don't have a Request and Response to cache. And while you could create one of each it's adding extra runtime cost.

I think a CacheStorage API should be more generic, like lru-cache package API, not associated with the Fetch API, specially to be used server-side.

For Cookies, the Remix Cookie API is great IMO, not sure if they want to move it here or keep it as part of Remix/RR.

skabbes commented 1 day ago

Thanks Sergio, I do agree that a lot of use cases will need a more general purpose cache, but I think there are plenty of existing libraries for that already in existence. I'm not really talking about that.

What I mean is "allow caching to work in a server context the same way it does in a browser context". So if I write a bunch of code that works in the browser (including receiving cookies, and having them sent back up when I make future requests), then maybe there is a way to make that same code work on the server. I think that would require cookies, and caching (and I'm sure a few other things I'm not thinking of).

Being honest with myself on my particular use case, I'm not sure I would use it myself either - but thought I'd raise it because it definitely fits the philosophy laid out here and in Remix too.