How to invalidate a single file on user content update

Let’s say I created an app on Netlify that uses 11ty to render database content into static files on build time. Nice.
Let’s also say, that I want users to be able to manipulate that data.

When a user creates some new content and that content gets into the DB, a Netlify redirect renders that data into a page dynamically until the deploy comes along the next time and updates the page. – I got this far and it works like a charm. :slight_smile:

Now, let’s say the user later comes back to his page and updates some data on it. It would be an hard NO, to let the user wait until a whole new build of the entire application has gone through until he can se his changes on the site right?

So: Is there a way to tell Netlify to invalidate (or delete) only a single html page in the active deployment until the next build comes along? …that way, the user would the be redirected to the dynamic (lambda-based) rendering of his page and be happy. Then, when the next build comes along, his page will be static (and up to date) again until he changes his data again.

Is there such a thing? Can I somehow invalidate specific pages?

…or do I need a completely different approach to user UPDATED (in contrast to created) content?

Kind regards,

@j-o-sh Welcome to the Netlify community. I never do anything this complex in JAMStack, but it seems to me that instead of re-building the page for each change you could reference an API that would keep the dynamic portions of the page up-to-date and leave the static code alone.

Just spit-balling here.

Hi Greg,
thx for the warm welcome :pray:

Well it is a bit about progressive enhancement here. So yes, I could simply roll out an SPA on Netlify and not bother with those questions. But I kind of like the idea of being able to provide a ‘data-complete’ site even without clientside javascript.

…and I am actually 90% there. The only issue I am having to get this complete is why I am turning to the community now. :wink:

If there was some kind of way to tell netlify that “Actually that particular page isn’t up to date, please threat it as if it wasn’t there.” then we would be able to do so. :slight_smile:

I don’t know the answer, but rather than telling Netlify something, it seems more straightforward for the visitor to tell your website that the latest content is needed. Netlify, being serverless, with content on CDNs around the world, is not the ideal target for such messages, I would think.

Hi, @j-o-sh, there is a similar question asked in another topic.

It isn’t the same question you have but I give some detail about what a “deploy” looks like in our system and why a complete deploy is required to change a single file. That information can be found in this post:

If there are questions after reading that, please let us know.

Hi @luke

Thanks for the reply. :slight_smile:
Yes, I saw that other topic as well and was kinda hoping for a shortcut :wink:

I will now refactor my app to work around that. I may be able to redirect to the dynamic version of the user’s page on the basis of a query parameter or header field. :thinking:
…that way, rebuilding the page itself isn’t as time critical anymore and the whole architecure is better for it, now that I think of it. :nerd_face:

Still, on the topic of invalidation: I get the atomic deploy bit and Do please stick with that btw.

I am wondering though… My usecase of deleting a single page could actually still be done without braking that though and it may be a great addition to the Netlify toolkit.

Since you have all the information and hashes of all the other files that belong to a deploy already it should be possible to create a new atomic deploy with a single file missing and all the other file hashes intakt by simply calling an api that only needs to know the filename of the file to delete.


1 Like

Fundamental changes like this don’t happen overnight and I’m sure that you can appreciate that. We’ll have to see what direction the product takes, ultimately! You might be able to do something clever with caching unchanged data, perhaps using build plugins, in order to keep build times down, but this would need some thought and engineering. It would still require a build but you could potentially get the build times down.

That said, I’m glad that we can work around it!