Red Tortoise Architecture
mattkaras.info
mattkaras.info
> 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.
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?
I don't trust the article author to understand this based on the choices made.
It is a good example to bring up because front end validation is not business logic, it is presentation logic. For some simple use cases that might not be obvious to many people but let's just consider a sign up form accepting an email address and a password. There definitely validations you want to perform in both places - the password needs to be 10 characters and have at least 3 of numbers, uppercase, lowercase, and special characters. Those exact password validations will be the same in both the UI and API. But let's consider the email. The business rule here is that only deliverable emails that are openable by the person signing up should be accepted for new users. You cant validate that on the front end. The best you can do is check for an @ symbol or run a more complicated regex (whales be there) before passing it off to the backend to actually send an email, encode signup details into a special link, and do all the work necessary to satisfy the business rule.
Its trivial to further drive that point home that UI validations are not business logic even when the same validation appears as part of business logic. You do some minimal checks to save the user time on the UI, but those shouldn't even be looked at as validations. They should be thought of as affordable for the user to prevent wasting their time with trivial, predictable errors.
The unfortunate truth is that our industry is full of examples where people have done exactly this. With predictably bad results.
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.
> For the front end – use whatever technology your front end developers prefer. Just keep things as simple as possible.
There are quite a few react nextjs etc etc apps that could benefit from being a little more on that end of the spectrum.
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.
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.