Short answer to your opening question: Yes, I believe they can be.
I’m using regular Ecto.Schema for representing database data, but I do not use those same Ecto.Schema structs for driving the user interface. I represent form data using Ecto embedded schemas and their related Changeset processing functions to represent UI/External API data (“UI data” collectively herein) for the purposes of having a ready made validation framework of that data.
More to the point, I don’t want a tight coupling between UI data and the database model because in many cases what works the best for the database structure isn’t necessarily what works the best for user interactions with that data. From the software design side, I want those separate interests to be clearly independent; this way I’m encouraging form design and form data handling to do what’s best for the user interaction in question and the database related code to do what is best for the information architecture. Yes, there is a point where these two interests must come together, but that translation from UI to data oriented business logic can be handled in a discrete, clear way independent of the direct UI and database related concerns.
In a situation like yours, my sense is you only have one of the two concerns that my project has: dealing with the user interface. So it seems to me is the real question you need to answer is: “Does the Ecto.Changeset methodology, a ready-made, well-known, widely-used system for data validation, bring enough value to the data validation problem to make it a worthwhile pursuit?” For many (maybe most), the answer should probably be “yes”; but I’m guessing on that last point. Otherwise, you need to think what alternative is better/simpler/closer fit for your project.
