A better starting post would have been to explain that, tell us something about it, rather than ask of anyone has tried your new framework.
| [reply] |
Creazilla on Perl (abbreviated as Crop) is a Perl framework with the main goal to make writing web scripts much easy.
No wide experience is required to programming a top-level script.
The SQL-layer is hidden from a programmer.
Crop implements:
class attributes inheritance
automatic object synchronization with warehouse
http request routing, parameter parsing
multiple warehouses of different type at the same time
role-based access system
The Crop has lightweight, simple and clear architecture, that makes changes to Crop itself simple. Crop uses common Perl syntax. Getters/setters are the only code Crop generates implicitly, so debugging is easy.
| [reply] |
"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] |
| [reply] |
