One guideline I would follow is:
Statically type everything that a service needs to inspect to do its job, and no more, but without introducing a layering violation.
So, for example if a component accepts this input:
{
"timestamp": "2022-06-17 00:00:00",
"data": {
...
}
}
Guidelines like this are operating on something like the Platonic ideal shape of problems. In any real world project, you need to consider the cost of handing a malformed `data` blob downstream, as it's never free.
Architectural model or pattern might be a better word than guideline. You benefit by collecting a catalog of patterns more than you do by trying to internalize guidelines.
Similarly plaintext is an example not a requirement. Like any analogy it breaks down at the extremes but that doesn't mean the analogy is a bad one.
It would be interesting to know exactly how many no/low-code solutions are deployed in comparison to custom code solutions, and what type of business cases they serve currently... I think the results of that study would really make a lot of devs switch fields of expertise. Almost every employer is calling me about DevSecOps positions, while app design and development are an afterthought due to prevalence of low/no-code solutions because langs have become so convoluted and specialized in hopes of creating a monopolistic work dependency... Sorry to vent, but solutions simply are overcomplicated too often now, and most of the people making technical decisions are non technical, and not equipped to keep up with the ever-changing terminology and jargon used in the dev world, much less knowing the differences in languages and terminology.
Over complexity and tech jargon are some of the most painfully alienating detriments to development in my experience. I think we would do a lot of good if we really got back to breaking down use cases and their individual (right-fit) solutions rather than sticking to redefining entire disciplines and forcing new terms that aren't properly descriptive frameworks, tools, and methods onto the industry as if one great new shoe fits all feet... You know, simpler jargon is better.
So if you wanted to be able to do N things (grep, word count, sort) across these M file types... you had to write N*M functions, each a bit different.
Unix simplified this to having everything as a text file (a special case of a file of bytes). This made it possible to have a set of N tools that could work on any part of the system, instead of 1/Mth of it.
The pipe operation allowed tools to be composed, you could grep, then word count, etc. This greatly increased the amount of computation that could be expressed as a task straight from the command shell, without having to write new tools.
So this redistributes the problem instead of solving it.
JSON is a file and interchange format - more technically a protocol.
It is not a data type.
> It is not a data type.
Although me, and I'm sure many others, have abused JSON and used it as a data type, I totally agree with you. However, GP was using JSON as an example of a more general idea. I needed to aggregate similar data across many different tables holding information collected from web scraping - typically one table corresponds to a particular service, and each service has it's own spider. My approach was to define a data model that contains all the information that I care about then write classes per service to convert its data to the format of the aforementioned data model. While the model can be serialized as JSON, it's composed of standard Python data types/classes and I don't constrain its design to be more amicable to serialization. Point being, while JSON is an intuitive example and can be a good go-to if your data matches it well, there's many ways to solve the N*M problem in this particular context.
An example of a narrow waist would be CSV - everything can export it, most things can import it, and you can usually fix whatever errors were introduced.
It also sucks bigtime.
You have M languages, and N computer architectures. You want a compiler from every language to every architecture, but don't want to write M*N compilers.
One solution is to make a virtual machine. Now, you write M language-to-VM compilers, and N VM-to-cpu compilers, so you only have to write M+N compilers.
It supposedly solves the N*M problem (so it’s an interface?), but it can’t be statically typed (so the interface has to be implicit?), and success stories are HTML5 and the x86 ABI (so it does require explicit specification after all, and huge amounts of it? Just look at the size of that Intel ABI book…), but also, it must be plaintext (so not like x86 at all?).
I’m not trying to be mean because maybe there’s something there that I miss, but frankly, I don’t get it, at least not yet.