We've been talking a lot recently about how to enable more small to mid-sized projects by avoiding a lot of the trappings of complex modern stacks.
-
We've been talking a lot recently about how to enable more small to mid-sized projects by avoiding a lot of the trappings of complex modern stacks. I think we should talk more about how the data layer fits into this. Both on frontend and backend.
https://social.polotek.net/@polotek/113170675996221391 -
Most of my focus is on building data-driven web apps. That context is important. I think there are many other kinds of projects that have different affordances and constraints.
Within the context of data-driven web apps, I do think it pays off to give ourselves more tools around managing the data layer. I would make the strong argument that the data model is actually the most important part in terms of delivering the right value.
-
I think we can see evidence for this pretty easily. When you're a building dynamic web app, there are two parts that you end up iterating on a lot. One is the UI. Because you're working on human interaction. There are lots of details to get right there.
The other is the data model. As you try to express the features of your app, you often have to modify and update your data a lot as your understanding of the problem space evolves.
-
We've talked a lot about how we want to give ourselves of tools for iterating on the UI. I think we've gone astray and need to regroup. But we've acknowledged the usefulness of UI tools instead of trying to work directly with DOM and vanilla js.
The same is true for the data layer. But in my opinion we have not nailed this area in the frontend. It still feels bad in a lot of ways. On the backend it feels much better, and the main reason in my opinion is we've gotten much better at ORMs.
-
In my message above about ORMs, I did say "when they're used responsibly". That is worth it's own thread that I don't think I have energy for today. It's very possible to go astray with ORMs just like the other tools we've been discussing. But there are a core set of capabilities that I think are highly valuable and worth it for most projects. Even small-ish ones. I'll try to talk more about that at some point.
-
@polotek
I try to avoid heavy ORMs that generate SQL. I used one on one of my biggest side projects. After months of frustration, I swapped it out for a query builder and was able to delete almost half of my server-side code.That said, I'm a big fan of query builders and micro ORMs that just map SQL results to class instances (e.g. Dapper).
I think most devs would be surprised how quickly they can learn 90% of the SQL they'll ever need. No more than a day in most cases, I'd bet.
-
@isaaclyman I disagree on a few different levels. I think we love to use this sort of rhetoric that says "it'll be simple, I promise!" It's self-defeating in my opinion.
-
@polotek
Fair - I should be careful about that. -
@isaaclyman saying that web developers should really learn SQL is a standalone statement. And a pretty reasonable one.
-
@polotek I absolutely agree with this thread. In my own approach to the small/mid project I’ve set criteria on what turns out to be “define the data ontology, persist data of that shape to a store, and query it arbitrarily. Iterate the data model and iterate the queries without database migrations”. Doing this practically has meant writing a lot of queries in server handlers to shape the data for the front end, but it works REALLY well and let’s me build complex data driven apps incredibly fast
-
@nk does this presume you're using a non-RDBMS store? I'm looking specifically at "without database migrations". I think that's fine. But I think the other option is to lean into database migrations early in a project. Make it easy to iterate on the data model. But making migrations "easy" is a whole skill that most devs don't have.