News for hackers. Stuff that matters.

A comment on The Simplicity of Single-File Golang Deployments. Parent comment

Re:The Simplicity of Single-File Golang Deployments by zer00eyz on Wednesday March 22, 2023 @11:05AM (#35262160)
OP here,

How are you doing caching without a mod time?

https://github.com/golang/go/issues/44854

Are you re-naming or hashing for cache clearing?

[ Parent | on HN ]
Re:The Simplicity of Single-File Golang Deployments by acatton on Wednesday March 22, 2023 @11:33AM (#35262640)
I'm not the author of the post, so I can't tell you.

What I do in my projects is that I tell varnish-cache to cache assets in "/static/..." forever. And when I have a "curl -X PURGE <varnish_endpoint>" as part of the "ExecStartPre=" of my go binary.

• https://varnish-cache.org/docs/trunk/users-guide/purging.htm...

• https://www.freedesktop.org/software/systemd/man/systemd.ser...

[ Parent | on HN ]
Re:The Simplicity of Single-File Golang Deployments by ed25519FUUU on Wednesday March 22, 2023 @11:35PM (#35270238)
Clever solution! Why not make it part of the startup of your binary?
[ Parent | on HN ]
Re:The Simplicity of Single-File Golang Deployments by acatton on Thursday March 23, 2023 @03:44PM (#35280278)
Sorry to reply a day later. GP here, it's a simple separation of concern. IMHO the binary should not be aware that it is cached and/or how it's deployed. I separate "business logic" from "devops", and I consider purging the cache to be "devops". This is why I let systemd do it.

Of course, at the end it's a question of preference. People might disagree.

[ Parent | on HN ]