I've been hearing about it going both ways right now. Some really love the addition of WebPack while others dislike it. From that article, I don't think the Ember quote really applies to the way WebPacker is handling the entry points, but could be a problem that they experience. I think that WebPack will be the way to go in the near future so it is worth the effort to become familiar with. I think the migration of an existing application from the asset pipeline to WebPack will likely be painful for many. Since I do not have the frustrations the author of the blog post has with even some larger applications that I support, I do not see myself adding WebPack into those environments. For newer applications and ones that would benefit from having the managed javascript, I would likely lean towards WebPack.

I completely forgot about that site! Thanks!

This is the config that I use for nginx/puma. The puma.rb is within the rails application's config folder.

nginx.conf

upstream backend {
  server unix:///var/run/puma/my_app.sock;
}
server {
  listen 80;
  server_name _ localhost;
  access_log  /var/log/nginx/access.log main;
  error_log /var/log/nginx/error.log;
  large_client_header_buffers 8 32k;
  root /var/app/current/public;
  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_buffers 8 32k;
    proxy_buffer_size 64k;
    proxy_pass http://backend;
    proxy_redirect off;
    # enables WS support
    location /cable {
      proxy_pass http://backend;
      proxy_http_version 1.1;
      proxy_set_header Upgrade "websocket";
      proxy_set_header Connection "Upgrade";
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }
  
  location /assets {
    alias /var/app/current/public/assets;
    gzip_static on;
    gzip on;
    expires max;
    add_header Cache-Control public;
  }
  location /public {
    alias /var/app/current/public;
    gzip_static on;
    gzip on;
    expires max;
    add_header Cache-Control public;
  }
}

config/puma.rb

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
threads     2, threads_count
port        ENV.fetch("PORT") { 3000 }
environment ENV.fetch("RAILS_ENV") { "development" }
workers     ENV.fetch("WEB_CONCURRENCY") { 2 }
preload_app!
before_fork do
  ActiveRecord::Base.connection_pool.disconnect! if defined?(ActiveRecord)
end
on_worker_boot do
  ActiveRecord::Base.establish_connection if defined?(ActiveRecord)
end
plugin :tmp_restart

For the filename, it can be handled a few different ways. Let's say you have a user model and the user model has_one_attached :image

If you're manually uploading an image then you can override the filename at the time of attaching it.

uri = URI.parse(URL_OF_IMAGE);
filename = File.basename(uri.path);
io = open(uri);
content_type = io.content_type;
user.image.attach(io: io, filename: filename, content_type: content_type);
user.save;

In this same example with a user and a image, we can get access to the image afterwards.

user.image.blob.filename
=> "whatever.png"
user.image.blob.filename = "newname.png"
user.image.blob.save
=> "newname.png"

For banning a file, I think you're heading in the right direction.

I would have a separate model for files that are uploaded for a user. Something like a User has_many Datei and Datei belongs to User.

The Datei model (german for file because I wouldn't want a model called File) would have a few attributes plus whatever else needed

user_id:integer:index
banned:boolean, default: false

The model would have something like has_one_attached :document.

So now a user can have many files (Datei) and each file has an attached document. You can flag the file as banned (or whatever else params).

Very cool!