Just because your TODO app only needs a BLOB storage with OIDC for the backend does not mean that "all of the complexity is in the frontend".
Pick a random Fortune-500 company. Their IT system complexity will be dominated by the "backend". Easily 90-99% of their complexity and budget will go into building and maintaining those systems.
There are quite a few react nextjs etc etc apps that could benefit from being a little more on that end of the spectrum.
> For the front end – use whatever technology your front end developers prefer. Just keep things as simple as possible.
Say I have a web application, written in JS running in the client browser. It uses the REST API.
I also need an Android app.
Does the Android app use the same REST API? If so, is the business logic re-implement both in the front end web JS code and inside of the Android app?
Or is the business logic embedded in the API?
If the rest API is pure, it will provide low-level CRUD operations with minimal business logic. The business logic will need to be written in each frontend. Making sure the business logic is correct and in sync across the front ends becomes a challenge.
If the business logic is embedded in the API, then many of the API endpoints will be less REST and more RPC style. But then the utility of Django REST framework is diminished.
How would you navigate this?
Frontend? You can implement it in a shared library and cross compile. Or implement it in a DSL and interpret (or compile) that for each target platform.
Is that overkill? Then implement the bits (it's almost always a subset) you need in the frontend.
Don't like that but your app can assume an internet connection? Then keep a connection open (i.e. Signal R) and call procedures on the server.
I don't trust the article author to understand this based on the choices made.
> There are a couple of reasons for this. Primarily I feel like the access patterns for the customer are sufficiently different to business access patterns and have different requirements.
The central problem I see with every article like this is the author's "business" and my business are entirely different universes. "Different requirements" is the entire game. Everything depends on the customer's expectations. When I read stuff like this I sometimes wonder if we are even speaking the same language.
For me the "Red Tortoise" architecture is to start with A SQL database and iterate the schema with business owners and customers until everyone is so bored with how obvious it all is that they have to take frequent breaks for naps.
I could take articles like this more seriously if there was some kind of introductory section that explained the actual business/problem that needed solving. Otherwise, this feels like a pointless shiny technology rabbit chase through the fields of "what if?".
But I can't think of an obvious class of business problems where the database schema for a customer facing system wouldn't be served by working hand in hand with the customer.
But, that is probably due to my cognitive limitations, lack of specific experience, or absence of knowledge regarding the context you are thinking of.
Can you give some context to the sort of problems you are focused on? Thanks.
Even custom, tailored software often gets deployed as SaaS these days.
With how many round trips that are happening due to serving clients a static page, I wouldn't call that winning a race, but I can see how tortoise may be accurate in that case.
