Anything like Rails ActiveStorage coming to Phoenix?

Hey @pillaiindu can you expand on this question to talk about what ActiveStorage does and what about its approach would make sense to translate to Elixir?

it is a file upload system, new in Rails 5.2, similar to Arc Ecto.

It also allows to switch platform easily, like switching from local, to aws, to google cloud IIRC.

Did You have a look at Arc Ecto @pillaiindu ?

I’m currently building an over-engineered file management solution for micro-service architectures…slowly. I’ll post about it when I think it’s beat into better shape.

If you don’t like how Arc works you could build your own with ExAws.S3, pre-signed urls and a files table with belongs_to associations to your other records in Phoenix. That’s most of what Active Storage is doing anyway. You might also look at Bitbucket as another option to Arc.

My concerns are with how a file-management solution would to fit the multi/micro-service architectures - there’s more to think about with those requirements in mind. On one end you need to define a behavior all the adapters should implement, and doing so generically with varying API’s between major storage services (Google, Azure, AWS, Digital Ocean). Right now I’m building it as a set of OTP applications using Ecto and Postgres for persistence and queries with a separate core application for handling commands, monitoring uploads, and fetching pre-signed urls (Phoenix for web layer only).

The set of features for Storage Service integration that makes sense in Ruby/Rails doesn’t make perfect sense in Elixir/Phoenix. From what I’ve looked into Active Storage, it’s largely built with the assumption that you only need to associate files to Active Record. Active Record is CRUD, and in the world of Elixir, CRUD is just one option. Most file management problems I’ve worked with also require a file to be attached to multiple records/ids across separate applications and platforms. I want to be able to manage files in one place, but re-use and associate a file to any service that needs upload capability; there’d need to be some kind of tagging and event-messaging integration that’s flexible enough to work with different kinds of micro-service architectures.

Anyway, just thinking out loud - sorry for the long response.

While I totally agree with you about differences between stacks and Active Record and everything you said,

we need to understand the root of these questions.

It is not technical the root of these questions most of the time coming from Rails/Ruby folks. Many of them, included me, don’t know how exact technical details of the things we use.

When people ask these questions they care about connivence, saving time, no having to think about X problem but simple use something that solves it.

Is that good?! Depends, all depends.

Arc and those solutions are no up to Active Storage level yet and so far from my research.

The biggest perk of ActiveStorage (when I looked at it) was that it focused on uploading images and then doing transformations on request rather needing to know all of them on initial upload.

This is similar to the approach that you would take using imgix and IMO is the ideal way to handle image transformations.

Combine ARC with an imgix account and you’ll get a better experience than active storage (for images).

With all respect to Arc author, I think the package is outdated and poorly maintained.
Other solutions are either low-level (Plug.Upload, ex_aws_s3) or immature (belt, bow, upload, etc).
File handling is such a frequent requirement and crucial part of many apps.
Maybe ecto/phoenix/absinthe core team could help the community with one well-designed package?

I’ve been using arc. I haven’t deployed my app yet, but the functionality is there to:

• Upload a file
• White list specific file types
• Ensure uploads aren’t over a specific size (with Plug.Upload)
• Use imagemagick to create different sized images and save-as a specific file type

So far it’s been working pretty well with local storage, but at the same time I wouldn’t mind seeing something more official. It looks like arc / arc_ecto is in maintenance mode and issues are quickly stacking up.

Why do you think, Belt is immature? Have you had any problems with it so far? It works fine in production for me
(Disclosure: I’m the author of Belt)

So its true the Arc maintainer is looking for help for a long time without much success. But most of the open issues are feature or support requests, not actually problems. We’re using arc_ecto in production without issues and did find it very convenient and easy to use. What are the actual problems people have had while trying to use it?

Without specific complaints this is very nonconstructive thing to say.