4 ms·
As for the first two: I would assume that you’d put nginx or some other reverse proxy (or a network of proxies) in front of your application server anyway. Wit
by dgb23 4y ago
As for the first two: I would assume that you’d put nginx or some other reverse proxy (or a network of proxies) in front of your application server anyway.
With the appropriate headers and configuration you would have the same kind of performance characteristics and resource utilization. Am I missing something here?
As for the last point: you have 1GB of stuff in either case. And all of that stuff needs to be looked at. The difference is really the deployment: do you prefer to move everything in a single piece or would you rather make individual, fine grained deployments? Either has advantages and disadvantages.
I’m not sure how Go let’s you inspect embedded files in a binary though. There might be gotchas. An archive is probably more transparent and more general tools can be used.
- viraptor 4y agoAt some point the image size does start to matter. Both for local convenience and for the time of deployment. Also serving only the current version's assets will cause failures during a restart. If you have more than one container, there's a chance the page request will hit the new one, but the resource request will hit the old version - without the needed asset. And once you hash your assets, you normally only deploy a couple of extra files, not the whole 1gb. I don't get why people would want to keep them embedded (apart from convenience for a third party who will run it)