4 ms·
Ah, yes, the old "look how easy building your simple CRUD app in [new tech] is" article. These always seem to work great (and do work great for some use cases
by fatnoah 3y ago
Ah, yes, the old "look how easy building your simple CRUD app in [new tech] is" article. These always seem to work great (and do work great for some use cases) until things evolve beyond, and then one spends their day fighting the technology instead of actually building the product. Meanwhile, the n-tier dev you laughed at is still plugging away and getting some extra help because because the loose coupling between tiers made it easier to divide-and-conquer.
- lovasoa 3y agoI'm not sure what you refer to exactly, but none of the tech presented as solutions in the article really lock you into their model when things "evolve beyond". Quite the contrary, actually. Migrating from, let's say, Django, to something else requires you to basically rewrite your app from scratch. Migrating from SQLPage to Django requires you to run the standard django `python manage.py inspectdb`, then copy-paste your existing database queries, and your are ready to go.
- forgetfulness 3y agoORMs when you have to do the most basic selects and joins, with naive pagination: look at how easy it is, it's magic! Also ORMs when you have to do anything more complex, specially if they involve aggregations: welcome to my awkward undocumented APIs, you now embark on a journey through hard-to-search-through class definitions and source dives that you'll share with every programmer that will touch your code in the future.
- semicolon_storm 3y agoEvery ORM I've ever used has some raw SQL escape hatch you can use when you hit that edgecase. For the 90% of DB access that really is simple, ORMs are a pleasure. For that other 10%, if your alternative is raw SQL, just use the escape hatch and you're not worse off than if you had skipped the ORM.
- mrits 3y agoYou can also map or redirect the objects to database views
- javcasas 3y agoOoh, database views! What would be next?? Permissions? Triggers?? Stored procedures?? Go shove your views up yours, you maniac! /s, except for way many more ORM lovers than you think.
- hardware2win 3y agoI too love debugging stored procs and other database-oriented-programming constructs because somebody was scared to write code
- fatnoah 3y agoWayyyy back in the day, after the dotcom crash, I got moved from a SWE role in my company to the consulting (customer implementation) side to try to bring more rigor to their process. One of the first things I did was replace a several thousand line stored procedure full of pivots, transforms, cursors, etc. with a few hundred lines of code. As a bonus, performance improved by a couple orders of magnitude as well.
- forgetfulness 3y agoKnowing what to process in memory, what to delegate to the database, to the datawarehouses, or other heavyweight data-processing engines like Spark, is its own subfield, data engineering. Finding data engineers that can actually do it will become difficult in just a bit, as there's a goldrush to take on that role, and lots of people want in with some rudimentary knowledge of SQL and Python. Anyway, I'm always suspicious of people advocating for stored procedures, because those are version controlled if you're lucky, and I've yet to see them subject to automated testing.