"The SQL-layer is hidden from a programmer."
From my personal experience: Ouch! While hiding the SQL layer might make development easier at first, this will hurt really bad when trying to scale the thing. When you have lots of complex data (as projects tend to do when they grow), you will
- need to look exactly into how transactions are handled to make sure your whole stack (APIs, core application, database backend) adheres to ACID principles as much as possible. Especially if your systems works with financial transaction of any kind (incl. online payment, shopping carts, etc)
- need to decide how your data is split and unified and how the relations between it works, both for performance for minimizing disk storage (and backup sizes)
- need to fine-tune statements for performance
- need to use advanced features of your selected database to optimize processing
- need to look into server side processing (triggers, functions) to minimize data roundtrips between the database and the application
- have to think about splitting data between fast and cheap tablespaces (current data on fast SSDs, seldomly used archive data on cheaper, slower spinning disks
- need to deal with internal and external audits of your code. Both for security, but also possible in a financial and/or legal context. That means you will need to know exactly how the data is managed.
- need to deal with privacy laws like the EU "General Data Protection Directive (GDPR)". That means you might have to run data audit and/or make sure that you scrub some data as perfectly as possible. If you don't know exactly how your database backend works, you might be in trouble.
Not every point on this list will apply to every project. But I've worked on enough projects with database backends over the last 30 or so years that i have run into every single one of those issues multiple times. Currently, i'm working on a point-of-sales system (in Austria/Europe), so financial audits are like "Tuesday", and GDPR compliance is a way of life. The software also runs on both high end servers (multi-user, cloud stuff) and somewhat low end touchscreen cash register hardware (offline single user systems)¹, so optimizing is also something i do for every single release.
In conclusion: Yes, hiding SQL and database internals from developers may help some developers start a project without having to learn SQL. But it has some serious downsides in my opinion.
¹ The Jassway OLP116W, running Linux and our software is quite popular with our customers. For many, it's the perfect form factor. With only 4GB of RAM, i have to run a PostgreSQL database, our webserver/framework/POS-Sytem, custom printer drivers, two webbrowsers, etc. And i have to keep all financial data for the lifetime of a cash register (a decade or longer) in the database, that's just how the financial laws in my country works. And it all needs to be fast, because wasted seconds add up and will get expensive for a business when calculated over a year.
| [reply] |
Perhaps more than a copy & paste from the site, something more substantial? Why would anyone use this over Mojolicious or Dancer?
| [reply] |
This is not about a competition. If you're happy with Mojolicious or Dancer, go on with them.
| [reply] |
"Hey everyone, a new open-source Perl framework called Creazilla on Perl just launched. Has anyone tried it yet?"
This reply with the above response seems odd behaviour given your goal of bringing this framework to our attention. If you're unwilling to provide responses to questions without becoming defensive, why post in this manner? People tend not to enjoy click bait, preferring decent content or things with examples and documentation. The use of natural docs over the standard POD way or working likely doesn't make it appealing either. A duplicate thread advertising the framework over at XDA developers. I'm not sure what you expect to achieve announcing what you have in way that you did.
| [reply] |
