4 ms·

Thanks. I don't really see how the validation schema and ORM model would ever really diverge... it's basically just specifying the various fields that are requi

Thanks. I don't really see how the validation schema and ORM model would ever really diverge... it's basically just specifying the various fields that are required or expected and the types of those fields. Before I found SQLModel and I was separately using SQLAlchemy ORM and Pydantic, I would always end up with models that more or less looked the same but with just different syntax. And actually keeping them in sync was very annoying, since you would always have to remember to change things in both places. It's very natural to combine them. The beauty of how tiangolo (creator of FastAPI/SQLModel) implemented things is that an SQLModel class isn't just LIKE a pydantic schema and LIKE an SQLAlchemy ORM data model-- they literally ARE those things under the hood, so you can still use those libraries separately for more advanced tinkering and stuff "just works".

dennisy 2y ago
Yeah I had a good read of the concept. I do agree for most CRUD apps there will be no divergence. My concern is that this breaks layering suggested by most architecture frameworks.
- globular-toast 2y ago
  Well, for a start there is a strong tendency for devs these days to ignore the old wisdom of abstraction and layered architectures etc. If they keep doing it long enough they usually learn it eventually, though! But this kind of thing can work in a well-architected system too. You're basically just saying this API is pure CRUD. I simply record what the client tells me. Then you have to apply your business rules somewhere else. This is usually the event-driven approach. I just record commands/events, then some other code actions those, based on business rules. Where I think this goes wrong is not realising the business rules have to go somewhere else. I see this with Django a lot. You get started with just pure CRUD then someone says "oh, we shouldn't allow that record because xyz", and the whole thing starts to become a mess.
Attummm 2y ago
> I don't really see how the validation schema and ORM model would ever really diverge... If that were the case, then using a PostgreSQL API[0] that maps tables to APIs would be all that's required. However, the real world is messy. Requirements change, which could lead the project becoming a reimplementation of full framework such as Django. Django also comes with generic REST endpoints based on models thus giving you the magic, but still allows for all the different use cases and customizations that might present themselves during the full lifecycle of a project. [0]https://github.com/PostgREST/postgrest https://github.com/PostgREST/postgrest
- dennisy 2y ago
  That is a great point, if CRUD is all we need PostgREST would be all we need!
  - Scarblac 2y ago
    I feel it would be good to start with PostgREST and only start adding custom endpoints once what you need diverges from tgat. Although those could also be Postgres views and stored procedures, of course.

dennisy 2y ago

Yeah I had a good read of the concept. I do agree for most CRUD apps there will be no divergence. My concern is that this breaks layering suggested by most architecture frameworks.

globular-toast 2y ago
Well, for a start there is a strong tendency for devs these days to ignore the old wisdom of abstraction and layered architectures etc. If they keep doing it long enough they usually learn it eventually, though! But this kind of thing can work in a well-architected system too. You're basically just saying this API is pure CRUD. I simply record what the client tells me. Then you have to apply your business rules somewhere else. This is usually the event-driven approach. I just record commands/events, then some other code actions those, based on business rules. Where I think this goes wrong is not realising the business rules have to go somewhere else. I see this with Django a lot. You get started with just pure CRUD then someone says "oh, we shouldn't allow that record because xyz", and the whole thing starts to become a mess.

Attummm 2y ago

> I don't really see how the validation schema and ORM model would ever really diverge... If that were the case, then using a PostgreSQL API[0] that maps tables to APIs would be all that's required. However, the real world is messy. Requirements change, which could lead the project becoming a reimplementation of full framework such as Django. Django also comes with generic REST endpoints based on models thus giving you the magic, but still allows for all the different use cases and customizations that might present themselves during the full lifecycle of a project. [0]https://github.com/PostgREST/postgrest https://github.com/PostgREST/postgrest

dennisy 2y ago
That is a great point, if CRUD is all we need PostgREST would be all we need!
- Scarblac 2y ago
  I feel it would be good to start with PostgREST and only start adding custom endpoints once what you need diverges from tgat. Although those could also be Postgres views and stored procedures, of course.