Security checks in API code should always live as close to the user as possible (such as in the route handler)—deeper code paths are often changed without consideration for security.
Nice reference for organizing Go codebases: https://docs.gitea.com/contributing/guidelines-backend
When writing services, it’s tempting to predicate resource cleanup on client disconnects and other external signals. But this is a recipe for resource leaks. (There are many customers who will accidentally leave WebSockets open and so forth.) Besides, it’s bad for a program to externalize its resource management.
In Go, always accept and use a context in any long-running call. Had a bug where a GetWorker() call spins until a worker is found even if the request context is canceled!
Project idea: Write a virtual file system that proxies your local filesystem to a mounted SSH server. Useful + good intro to systems?
Claude 3 has this really annoying habit when you ask it to fix a bug in your code—it shows you some code, claims that it has some problem THAT IT CLEARLY DOES NOT HAVE, and then shows you the same code as the “fixed” version.