I watch this show, but one of the most annoying things about it is that the traitors are incentivised to murder the smartest, most intuitive players first, leaving people they can manipulate easily. Maybe you could argue the smartest move is to play dumb.
This is at its worst in the second Australian season, which is an incredibly frustrating watch.
I recently came across (but haven't yet used) Typia, which appears to let you do validation with regular TypeScript syntax: https://github.com/samchon/typia
Although the advantages are real, I can't say I have had much opportunity to implement schemas like this. The extra complexity is usually what gets in the way, and it can add difficulty to migrations.
I think it would be useful in certain scenarios, for specific parts of an application. Usually where the history is relevant to the user. I think using it more generally could be helped by some theoretical tooling for common patterns and data migrations.
Another misconception is that they somehow scale horizontally "better". They do let you scale components independently of each other, but this isn't as useful as a lot of people seem to think it is.
Obviously you're in a better position to evaluate the trade-offs for your application than I am, so I'm not saying your decision is wrong, but this can potentially decrease availability if your application depends on both PostgreSQL AND Redis to be available to function.
If you're already using Postgres, you can avoid increasing operational complexity by introducing another database. Less operational complexity means better availability.
You can atomically modify jobs and the rest of your database. For example, you can atomically create a row and create a job to do processing on it.
I'm a type enthusiast, but dynamic languages make a lot of sense for small programs that either give you an immediate answer or fail to run (i.e. not long running, few branches).
In those cases, the difference between a compile-time check and a run-time check is much smaller.
I've worked at a place where this was cargo-culted and it worked horribly. All the worst aspects of 'services-first' design.
I think this works much better when each team is working on what could be regarded as a complete end-to-end product e.g. a database. It works poorly when each team is working on part of a product.
The discussion here is frustrating because people are assuming that you'd pass the SQL directly to your database backend and expose your entire schema and all your data.
SQL is just a query language, just like GraphQL, and is no less 'secure'. You can still have a layer between the front end and application database.
A practical way to use SQL would be to expose the subset of data that is visible to the user and allow that to be queried by SQL, just like it would be by GraphQL or REST.
To add to that, I think the biggest thing to take away from Conway's law is that splitting teams of developers becomes a technical problem. If your goal is to efficiently build a product, technical expertise needs to go into that decision.
This is why I say Conway's law is a bad thing for modules (regardless of how inevitable it is): technical considerations are often not taken into account, and technical design is ossified by team structure.
I think what I'm trying to say is that my definition of a module as a "unit of encapsulation or understanding" is the more inclusive and general one, as it includes network and process boundaries. The OP's use of the word is the restrictive one because it excludes language-level modules. I say this because security and isolation are not typically goals of language-level modules.
This is fine to talk about, of course. It's just confusing to reconcile the article with my definition of modules, which I thought to be the common one.
Specifically in the context of modules, I think it is a bad thing. It's hard to describe because I do it quite intuitively, but (very broadly) the way I find module boundaries is by trying to find the minimal interface for the maximal amount of code. For me, this usually revolves around some kind of data structure.
Importantly, this is completely independent of team structure. The boundaries between teams are not necessarily the minimal interface.
IMO this is a confused take on modularity. I think isolation and security are related concepts, but not what modules are for. Those things have to follow module boundaries, but they're not the goal of modules. For me, modules are about understanding; in order to use this code you don't need to read all of it, you just need to understand the interface. Modularity is for humans, not computers.
They do often follow Conway's law, but that's not a desirable thing. Most modules are outside of that kind of context -- they're in libraries written by people you don't communicate with at all!
I'm interested in people's opinion here. I'm also planning an article on the relationship between services and modularity.