To ORM, or Not To ORM

For reasons beyond me, many developers try to avoid SQL and they use various ORMs instead. Some argument they don't introduce new language into the source code, others claim it would be portable across multiple DBMS.

There are ORMs with no different code than SQL would be. For example, simple query, like:

1. SELECT id, name
2. FROM employees
3. JOIN contracts ON c_id = e_id
4. WHERE active = 1

would translate to:

1. x

x

https://blog.logrocket.com/node-js-orms-why-shouldnt-use/#1-learning-wrong-thing

Node.js ORMs: Why you shouldn’t use them - LogRocket Blog

GitHub - typeorm/typeorm at stackshare

Full Circle

In late January I started working on a small intranet app, exactly to my liking. I had such thing in my shelf and in my head already, and this was exactly what I needed to follow through.

I was really happy about the progress I made there, and it became my pet project very soon. I finally finished my idea for managing modules (inspired by WordPress plugins) and it kinda clicked together. But what's often the case, my gut told me it's not optimal, until I found a case, when it falls apart.

The problem was that in some instances I needed the same page to belong to multiple modules, which wasn't possible. Eventually I decided to rework the concept, before it's too late.

I customized data model to suit the described case. I don't know if it's because of my mindset, but soon enough it started to look quite familiar. It didn't surprise me that much, that what I ended up with was an adaptation of Qedy's data model, only instead of objects I had pages and instead of elems I had features.

When this occurred to me, I renamed it to the Qedy conventions, because it's more suitable anyway and I spent over a year perfecting it, so I can think well enough along that line.

Before I started to rework the intranet app itself, I created a simple PHP script for managing data, with Adminer as inspiration. Partly as a proof of concept, partly as a tool, partly just for fun – I didn't make an old-school PHP script like this for years.

Object Elems in Qedmin

I must say, I was quite pleased with the full circle. I started with a completely blank slate, created a data model in a different manner, but iterated towards what I thought was a perfect universal data model at that time and apparently, I was right.

The only difference is I'm not going to utilize it to its full potential, because I want to have an option to tweak data in the database (even it's not a good practice) and Qedy's JSONs and particles are not good enough for that. This time I'll try to keep particles only for objects themselves (classes and relations), with data in custom tables.

Static website security

There are basically two options: you can do it in .htaccess, but you need a support for mod_headers. If your hosting doesn't offer that, you need to serve the static page by a PHP script.

I used a customized Neil White's .htaccess file:

1. # X-Frame-Options to prevent clickjacking Header always append X-Frame-Options SAMEORIGIN # Apply a CSP to all HTML and PHP files <FilesMatch "\.(html|php)$"> Header set Content-Security-Policy "default-src 'self'; style-src 'unsafe-inline'; object-src 'none'" </FilesMatch> # Block pages from loading when they detect reflected XSS attacks Header always append X-XSS-Protection "1; mode=block" # Prevent browsers from incorrectly detecting non-scripts as scripts Header always append X-Content-Type-Options: nosniff # Only connect to this site via HTTPS for the two years Header always append Strict-Transport-Security: max-age=86400

You may need to fiddle with it a bit, my webhosting was already sending STS header, so I didn't use that one.