5.0 KiB
Even more stupid than you think
We all know about the KISS (keep it simple, stupid) principle.
In fact, unlike what it looks to suggest. Keeping things simple is more difficult than one imagine at first1. The other adage from Einstein being:
Make everything as simple as possible, but not simpler.
—Albert Einstein2
And what is hidden here, is the fact that finding a way to build something that is simple need an internal comprehension of the system. To me this is typically what algebra is all about. Find a system as simple as possible that still respect a set of properties.
So after a few years of experience in software development everyone will agree with the principle. And this is a bit easy to agree with a principle. What is difficult is to really dig about how simple something could be.
So here are a few evidences about my experience about how far you can go. And if you don't like the word "simple" think about the word abstraction. The sense of abstraction is also quite large. If I wanted to be more precise, I would say, that a good programming abstraction is generally sustained by a good algebraic abstraction. What provide a good algebraic abstraction is the certainty that your system will be composable upon some properties. So the important word here is composability which is arguably superior to modularity.
Here are a few example about how far we could / should go.
CRUD+Search
With this simple abstraction you could build successful API.
(defprotocol CRUDPS
(create [this id value])
(read [this id])
(update [this id new-value])
(delete [this id])
(patch [this id new-partial-value])
(search [this partial-value pagination-parameters]))
One important detail is that we could provide "partial values". So we should have a language that should support the notion of "sub-object". And if you are doing this in javascript, this should be easy. In Java or Haskell, it might be a bit more funky.
So just that. It is even simpler than an ORM. You don't need more than that most of the time. If you force yourself to work within this restriction this give you immediately a few pretty good properties.
- Portability; This protocol is so simple to write it is easy to implement it for different DBs. Postgres, ES, MongoDB, etc…
- Scalability; as this only focus on a single table/index, you do not have to think about join. One of the most important property of my system is generally to never write join. And you can go surprisingly far without the need of any join. In fact, most of the time "fake join" are more efficient, et good enough for almost all user facing use case.
- Simplicity; by only using this API internally, it is easy to manipulate DB accesses.
Use HTTP, with 90% CRUD + Search. This is enough for most use cases. And by search, don't think about something too fancy. A sub-JSON will be enough for most use case. Then later you will probably want to add text search/matching. Why sub-JSON is probably superior to your SQL query? Because it is composable, more precisely this is a morphism, which SQL queries aren't.
What do I precisely mean by "sub-JSON"?
Simply the <@
operator in Postgres.
Or the basic MongoDB/ES search.
Not some system introducing complex structure.
So you want to match:
{"foo":"bar"}
// should match with
{"foo": bar,
"x": "y"}
// but shouldn't match
{"foo":"notbar",
"x":"y"}
//nor
{"x":"y"}
So this is a morphism with the following property:
(find x) AND (find y) <=> (find (x inter y))
Which is not possible to easily do with a SQL query. If you have a string representing a query Q1, and another string representing a query Q2. It is difficult to produce a query for Q1 AND Q2. Because, there are field selection for example.
For most modern web application/API you don't need to enforce strong constant on that either. For example, you can loose so much time trying to support a great update or patch. Doing so in a concurrent system is hard. If you don't care much, most of the time this will be perfectly ok.
So just with that and the correct data structure. No search by text, no join. Just 1 table, per data structure saving JSON + the ability to search by sub-json. We created, multiple time, a big reliable and nice to use API.
No surprise, no discussion about query optimization, no problem about scalability.
If you want a great overview of the subject, I highly suggest you to watch Simple made Easy video from Rich Hickey.
This is only attributed to Albert Einstein. He apparently said something similar but we don't have any strong evidence he wrote or said exactly that.