[nesarkvechnep]

Yeah, one of the worst practices. I've been working with Elixir professionally for 6 years now and I still see this sh*t everywhere. Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape. List of memberships? Keep them as a list with the same fields as the junction table. Top-level APIs taking maps with string keys as "params" so they can very easily be cast for a changeset.

[neya]

This was the only out of box solution when Elixir didn't support types. So, if you really did Elixir professionally for 6 years, you'd know that by now.

> Bad APIs, bad UIs because someone coupled themselves to the database structure and can't escape.

If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning and architecture overall as that is one of the very first things you do.

What you describe is an approach a lot of NoSQL fans use - use whatever works then, worry about datatypes later on. That's how you shoot yourself in the foot.

> List of memberships? Keep them as a list with the same fields

Again, using embeds_many or has_many works well too, using changesets - which is my point exactly. Not sure where the disagreement is here.

Your account is full of just ragebait comments at a quick glance, so I'm just going to leave it here.

[SuddsMcDuff]

> If you don't commit yourself to the database structures you defined at the time of application creation, then it just reflects poor planning

No it reflects the reality that requirements and applications evolve over time. You sound like someone who's never supported an application for more than 5 minutes.

[neya]

> You sound like someone who's never supported an application for more than 5 minutes.

If your application requirements change every 5 minutes, then you prove my point - you suck at architecting and should honestly just give your job away to someone more competent.

[nesarkvechnep]

The disagreement is on Ecto schemas used to represent databases tables from the persistence layer to the UI. Of course, use changesets to normalise user input but using the same schemas everywhere is a sign of immaturity as a developer. You really sound like someone who only does CRUD services. Real world is often more complex.

[neya]

> Real world is often more complex.

Which is why you architect before-hand with a paradigm of your choice, like DDD (Domain Driven Design) using proper contexts (which Phoenix supports) beforehand. That is the sign of a mature developer, not the other way around.

If your datatype for a column evolves over time to completely different types, it's just an excuse for poor planning and architecture. Eg. A string turning into an integer. That just sounds like someone junior would do with MongoDb.

> You really sound like someone who only does CRUD services.

You throw this like an insult, but in reality most applications can be simplified to just CRUD services. Chat interfaces? CRUD. Social Media? CRUD. Banking? CRUD.

[bbkane]

I haven't used Elixer but tt's generally a good idea for the UI to have a different data model than the database (even if it means you initially type almost the same thing twice and have to write a tedious translation layer).

This lets you evolve each part independently and use the "native" types frontend vs backend, which happens surprisingly frequently as the app grows

[neya]

> but tt's generally a good idea for the UI to have a different data model than the database

You're not wrong and most other comments are responding this from some sort of UI library perspective, like React / Svelte. However, if you're using even the barebones scaffolded UI using LiveViews from Phoenix, you don't have to do any of these. Phoenix will wire up the form to the changesets by default. Which is what I'm referring to.

[Kaliboy]

Phoenix does have that. ViewModels. I don't think its required to use though, but we always do.

[bcrosby95]

Sometimes types are worse than the alternative.

I obviously don't know your specific use case, but in my experience having the database schema reflect throughout a project means its either very small or the design is going to run into problems.

It also sounds like a potential security nightmare. We have a policy of never sending domain objects across the wire so nothing accidentally gets sent. APIs must strictly whitelist data structures.

The way this can work in something like an Elixir or Clojure: you have gradual types in most of the core code, but you translate it just before you hit the view layer (e.g. templates).

The great thing about dynamically typed languages is you don't have to declare a new type for each view. You just select out the data you need and expose it for the view. In Clojure this is as simple as a select-keys.