3 ms·

I assume there is. But that’s not the point I think. The point of embedding is similar to making a jar from an ops perspective. You “bundle” everything into on

by dgb23 4y ago

I assume there is. But that’s not the point I think. The point of embedding is similar to making a jar from an ops perspective. You “bundle” everything into one thing and you deploy that thing as single binary/archive. Less moving parts, less complexity. Secondly, providing etags/modified headers for serving static assets is not a hack. It’s just not built-in. But it’s perfectly fine to serve those directly from your app server with the appropriate headers, so proxies can serve them directly. In fact I would ask the reverse: why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? Personally I wouldn’t necessarily use a 3rd party library for this but to each his own.

dj_mc_merlin 4y ago
> why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? * different work profiles (streaming large amounts of compressed data vs small JSON requests/replies) means that different software is more optimal for each -- an application thread usually is a lot more powerful and does a lot more (and thus is slower in the general case) than an nginx thread * you're using your own compute on your own dime to do what your service provider is probably offering to do for cheaper * bloats the image size -- there is a productivity difference between working with a 150MB image and a 1GB one (debugging, easily diffing changes) Admittedly, these aren't problems for a one man startup or a very low traffic website, but these things do eventually matter as your system grows in size.
- 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 ago
    At 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)

by dgb23 4y ago

dj_mc_merlin 4y ago

> why use a CDN when you can use canonical features for deployment (Go embedd, Java jar etc) and serving (HTTP cache headers)? * different work profiles (streaming large amounts of compressed data vs small JSON requests/replies) means that different software is more optimal for each -- an application thread usually is a lot more powerful and does a lot more (and thus is slower in the general case) than an nginx thread * you're using your own compute on your own dime to do what your service provider is probably offering to do for cheaper * bloats the image size -- there is a productivity difference between working with a 150MB image and a 1GB one (debugging, easily diffing changes) Admittedly, these aren't problems for a one man startup or a very low traffic website, but these things do eventually matter as your system grows in size.

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 ago
  At 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)