So far I see more value in ontologies than graph databases. When using established ontologies naming does not become an issue and exchanging / understanding data becomes easier. You also push some of your code to the database "as data" and can reason on it better.
We are actually working with semantics / ontologies. The graph database is just our engine for storing the data. I am starting to think whether an ordinary SQL database could be just as useful.
Hetzner does not open port 25 outbound (SMTP) until you have paid your first invoice. I therefore believe them to handle this problem somewhat seriously.
I had great fun setting up Postfix and Dovecot recently.
However, I was very specific with always going for the minimum most simple solution. I do not have a dedicated database for instance, but use just mbox and POP3.
And I did not even bother much with anti-spam, I chose a super easy filter in Thunderbird instead, sending everything with 'unknown' in Received: header to the Thrash folder.
Getting accepted by others was also not much of an issue (but lots of details of course, PTR, SPF, DKIM, DMARC).
I have dabbled with the same problem with AgoRapide which offers queries through GET (although on a much simpler level than PQL / GraphQL).
I just present the query in readable form together with the output, letting the user choose between copy / paste the URL or copy / paste the readable form.
Never used it. First time I was introduced to an ORM (Hibernate) my instinct said to run away. Just too much complexity involved for little gain.
I usually find that my projects are well suited to key-value storage, often with a natural chronological order. In other words: A complex RDBMS table structure is not needed anyway. This again reduces the need for any ORM.
I run an IoT company where we do customer management without any special RDBMS system at all, I just built an HTML interface into the JSON API which in turn is mostly exposing a key-value store.
Not sure if this would qualify as a full blown customer management system though, although it does covers concepts like Customer, Gateway, Device, Payment, Notifications / Alarms, Support incidents.
Currently this has almost only a single-company use, but I would love to see other use the same concepts.
This kind of turns the API into a client application, that is, you do not necessarily need to build a user interface on top of the API, it is actually inbuilt in the API.
The main customer support application in a IoT company that I run is just such an API. The customers themselves of course are offered a real app on top of this API, but not having to maintain a dedicated application for the support department is a huge saving.
It is nice to get some reminders why I still use a so called 'dumb'-phone.
Very easy to use and with extremely long battery life.
And if I lose it or damage it, the replacement cost is a non-issue. I had a Nokia costing 79 NOK (approx USD 10) for over ten years. Eventually the screen died. Now I am using my daughters old Nokia, which I got free of charge because she swithced to Apple.
And even better, the kids can not demand 'better' or more expensive phones than what I use myself. That is where the big savings are :) :) :)
Good point, even more so because I use VLC myself because of the exact same reason, it plays anything. I just never thought of giving it URLs, only local files.