Hacker News new | past | comments | ask | show | jobs | submit
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.
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.

> 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.

loading story #48399864
loading story #48400084
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.
loading story #48399767
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

loading story #48399895
loading story #48397612