artem
Are Ecto embedded schemas useful without a database?
I am still new to elixir, so once in a while getting confused with the reasoning for basic stuff
Context
I am building a small service that is essentially a nice looking wrapper to an external API. It is somewhat similar to reading users, their organizations, orders, products via API and then presenting these nicely with whichever cool filters client wants (e.g. something like "find all products this user is expressed interest in).
I don’t even have any database, login happens via external system, everything is read and written from/to external API and several LiveViews + small contexts on top of Tesla-based REST client work very well there.
Data modeling
Building something without database is not very usual situation for me, so I naturally started with Ecto’s embedded schemas in style of:
defmodule MyCoolApp.User do
...
embedded_schema do
field :first_name, :string
field :last_name, :string
...
end
end
But I noticed that I am not really using Ecto’s capabilities much. I don’t need query building (or I don’t understand how to convert them into REST params for Tesla conveniently), there are no real repos that could make transactions possible - I use these essentially as just a Map with properties.
Now I’ve got to a point where I’d want to link different objects (temporarily, just one live view execution probably) and with a simple map I could do things like linked_user = %{user | organization: org} while with embedded_schema I need to learn and use things like build_assoc and other association related things.
What’s the point of Ecto in databaseless app?
Once in a while I see mentions on the forum that embedded_schemas work well without the database, but can’t quite get a reasoning why.
- I am certainly missing something basic, so could you please, suggest some reasoning or at least pros and cons of living with Ecto schemas and without when there’s no real database behind?
- Or am I wrong with the whole approach and something very different is better to be tried?
Most Liked
thiagomajesk
Ecto schemas are essentially DTOs… You use them to move data from one place to the other (including but not exclusive to databases). The advantage you have over maps is being able to define that information in a more type-safe/ structured way.
IMHO, the first thing that you need to consider before using an Ecto schema is: “Do I need to validate or transform this inbound data”? I use “inbound” here very loosely, as this can mean data coming from external sources (like a user form or an API payload) or data coming from other layers within your application (like context boundaries).
Exactly this. I find embedded schemas particularly useful to define value objects (if you are familiar with DDD terminology).
And this is why I like to think of schemas like DTOs… They can represent database records, but they are much more powerful than this… You can also think about schemas as “windows” that let you peek into a subset of your data. This is extremely helpful for doing things like Command/Query segregation and overall decoupling your data from your domain representation.
sbuttgereit
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.
Aetherus
One of my friends once told me that he wants to make every struct in his project an Ecto schema, no matter whether it maps to a database table or column.
I think he has his point. By making a struct an Ecto schema, we have a very good casting and validation mechanism for free.
Maybe I’ll try this idea in my future projects, too.
dimitarvp
More or less, yes. Especially embedded schemas and using schemaless Ecto are both amazing for (1) parsing and (2) validating data coming from the outside and then converting it to neat structs that obey the invariants of your business logic.
That’s really up to you though, you can just make them proper DB-backed Ecto schemas? Embedded schemas work well too but need a little grooming i.e. put_assoc et. al. at times.
andreaseriksson
Have you looked at Polymorphic embed?
https://hexdocs.pm/polymorphic_embed/readme.html
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Enabling companies to succeed by building software people love.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"