The problem with desperate monetization stunts like this video is that they rarely have any relevant content to show, and they are a formulaic output of mixing clickbait titles with 15min of inane fluff.
sql was built so people other than devs can use it, but we got stuck with it.
Not really. Being designed with UX in mind, so that it sacrifices conciseness for readability, does not make it something for "people other than devs".
Likewise, BASIC was also developed with UX in mind, and no one in their right mind would ever claim that it's not a programming language.
It’s long running, so you want a database so you can store your state. If you’re storing state, locking it into a state machine makes sense.
That's besides the point. Of course that the most fitting way to represent a state machine is with a state machine. The point is that implementing the transition table in a database table creates many problems while apparently solving none.
Which is what putting most of this stuff on the background accomplishes.
The part you're missing entirely is the complexity that's hidden behind the weasel word "most".
The majority of event handlers from a GUI app do not do anything complex, computationally expensive, or blocking. They do things like setting flags, trigger changes in the UI state (i.e., show/hide/update widgets) bump counters, etc.
No one in their right mind would ever consider going through the trouble of doing this stuff in separate threads/processes. "Most" handlers run perfectly fine on the main thread.
Nevertheless software changes, and today's onClick handler that sets a flag to true/false tomorrow is required to emit a metric event or switch a different treatment depending on the state of a feature flag or A/B test, or is required to write a setting to disk or something like that.
How do you draw the line in the sand that tells whether this handler should run on the main thread, should trigger a fire-and-forget background task, or should be covered by a dedicated userflow with a complete story board?
That's the stuff that's hand-waved away with weasel words like "most".
This blog post delivers a crisp mental model to tell which approach is suitable: follow the real time computing rulebook, acknowledge that each and every handler has a time budget, and if a handler overspends it's budget them it needs to be refactored.
Microservices are not just about scaling and performance but it is a core advantage. To say they have “nothing” to do with it is outright false.
They have nothing to do with performance. You can improve performance with vertical scaling, which nowadays has a very high ceiling.
It's not a coincidence that startups are advised against going with microservices until they grow considerably. The growth is organizational, and not traffic.
Microservices are about modular design and decoupling units of code from each other.
Yes, but you're failing to understand that the bottleneck that's fixed by peeling off microservices is the human one faced by project managers. In fact, being forced to pay the microservices tax can and often does add performance penalties.
The problem with this approach is that switching from vertical to horizontal is extremely hard if you didn’t plan for it from the start.
I think you're missing the point that more often than not ain't going to need it.
In the rare cases you do, microservices is not a magic wand that fixes problems. The system requires far more architectural changes that go well beyond getting a process to run somewhere else.
And if you’re not using Kotlin, you’re probably using Java for Android dev.
Java is the dominant platform for web services, and some companies including FANGs even standardized their whole infrastructure around it.
Also, Java is basically the default programming language in some degrees.
If you're worried about your degree's worth then you are certainly not he right person to talk about going through a shit university.
That's really not a DDD requirement. Having a domain model does not require you to preload data to run business logic. For example, you can easily have business logic that only takes as input a value object and triggers a usecase, and you do not need to preload anything to instantiate a value.