5 ms·
Yeah MVPs and mockups is exactly what ORMs are for, since they get you the first 80% for very little effort. Maybe it depends on the language, but this is defin
by crabmusket 3y ago
Yeah MVPs and mockups is exactly what ORMs are for, since they get you the first 80% for very little effort. Maybe it depends on the language, but this is definitely the way Rails and Laravel style framework ORMs are designed.
- mewpmewp2 3y agoTo me SQL is better for MVPs. It is transparent and clear, easy to debug and can do easily whatever joins, filtering you want to. ORM is more for future, because it abstracts away the database implementation, so you could in theory change the db or change some behaviour more simply. E.g. if you add something like deleted_at column, ORM can have a single place where to configure system to use it, but if you have SQL queries lying around you may need to find all spots to add that to your where clauses everywhere. But otherwise SQL is easier to work with in my view.
- crabmusket 3y agoWhat ORMs/languages do you usually work with? Dynamic language ORMs usually let you very easily add filters, work with relationships, etc.
- mewpmewp2 3y agoI started out with Laravel 10 years ago, but now I have been in the NodeJS Ecosystem for recent 5 years, so I've been working with different things, but lately mostly with Supabase, which has its own REST API abstraction, but now I've been lately starting to prefer just having a direct bare postgres client against it. This is for my own side projects/MVPs.
- alexanderchr 3y agoYeah I’ve found both Eloquent (Laravel ORM) and Entity Framework to be more than flexible enough and to produce surprisingly good SQL. You do need to keep an eye on the queries if produces though because innocent changes can make a huge difference in performance.