7 ms·

Red Tortoise Architecture

28 points by lucidguppy 3y ago

SoylentBob 3y ago
Seems like the hug of death already reached the site. It returns a "Error establishing a database connection" message right now.
dsabanin 3y ago
I choked seeing how frontend was relegated to a single box at the end of the diagram, given that it's complexity often dwarfs the rest of the system. Most backends these days can be had out of the box by using something like Supabase, AppWrite, Firebase or tons of others. These days web app backends seem almost too trivial to bother.
- danparsonson 3y ago
  Did you mean complexity of deployment? What does a modern front-end need beyond something to serve up resources at a reasonable rate?
- mhuffman 3y ago
  In many cases a front end is just a view of some API call which can be much more than a db query. Some times it is the other way around where the the front end is just pulling data and all the business logic is done in the browser. So I guess it depends on your needs.
- Etheryte 3y ago
  Quoting the article makes it clear the author doesn't understand the problem space. "Just keep things as simple as possible" is not an architecture. > For the front end – use whatever technology your front end developers prefer. Just keep things as simple as possible.
  - lucidguppy 3y ago
    Your correct I'm not super well versed on the front end. I was under the impression that a react app could be hosted on an s3 bucket with reasonable performance.
- pc86 3y ago
  There was a day not too long ago when the front end was a single box on a diagram. HTML forms posting to an API, then a redirect to a different page covered 99% of your front end. There are quite a few react nextjs etc etc apps that could benefit from being a little more on that end of the spectrum.
- hobs 3y ago
  A backend isn't just a database, it sounds like you've just made your frontend your backend as well.
- radicalbyte 3y ago
  What kind of systems do you work on? This might be true for a certain class of mobile apps / websites it is absolutely not true for significant systems. 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.
- evantbyrne 3y ago
  That's quite the self-snitch. Even the most complex web applications don't need a separate frontend server, let alone multiple. The only exception would be having an app or something that can't just render HTML sent straight from the backend.
koliber 3y ago
How does this architecture handle this concern: 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?
- ahoka 3y ago
  The proposed “architecture” doesn’t address this, because it’s a nothingburger. What about authn/authz, etc? The only good piece of advice here is to separate your management and customer data.
- arcbyte 3y ago
  Business logic is never, never, never in any UI. ALWAYS in the API. APIs with business logic have no bearing on RESTful vs RPC. None whatsoever. I don't trust the article author to understand this based on the choices made.
  - radicalbyte 3y ago
    I like it when people like that work at banks. You can have a lot of fun with "pure REST APIs which provide CRUD operations" on bank accounts. Especially when the important business logic - such as credits and debits - are implemented in the frontend :-)
  - isoprophlex 3y ago
    The whole thing defending that you must absolutely "ETL into NoSQL and do state management into a separate RDBMS" is a red flag for me, too.
  - 3y ago
amacbride 3y ago
The Hug of Death seems to have shown that it's not a * scalable * architecture.
- deleted 3y ago
  [deleted]
bob1029 3y ago
> But why the hell are you putting two databases into the architecture out of the gate?! > 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?".
- brudgers 3y ago
  I agree that context is missing. 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.
  - m0llusk 3y ago
    Government regulation compliance: It is necessary to make accounts, verify identity, request and pay for licenses. Following rules, displaying required notifications, enforcing compliance with fines or status changes all comes across to most members of the public as completely byzantine and incomprehensible. All of that needs to start with government officers who understand the related legal landscape.
  - gmfawcett 3y ago
    It depends. In some applications, the business users are SQL power users who live and work in the schema, and every bad design choice hurts them every day. But in others, the schema is fully hidden behind UIs and canned output (reports, dashboards, ETLs). It never sees sunlight, so many bodies can be buried. Even custom, tailored software often gets deployed as SaaS these days.
charcircuit 3y ago
>wins races 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.
aryehof 3y ago
Are non-functional requirements all there is these days? Instead of “developers, developers, developers”, is the new mantra “plumbing, plumbing, plumbing, (and infrastructure)”?
skrebbel 3y ago
I’m blown away how enormous this is. What kinds of greenfield projects are these? Two databases, an ETL pipeline and an orchestrator? Why?
blackoil 3y ago
And it is down now with "Database Error" as title. I sense some irony.

28 points by lucidguppy 3y ago

Seems like the hug of death already reached the site. It returns a "Error establishing a database connection" message right now.

dsabanin 3y ago

I choked seeing how frontend was relegated to a single box at the end of the diagram, given that it's complexity often dwarfs the rest of the system. Most backends these days can be had out of the box by using something like Supabase, AppWrite, Firebase or tons of others. These days web app backends seem almost too trivial to bother.

danparsonson 3y ago
Did you mean complexity of deployment? What does a modern front-end need beyond something to serve up resources at a reasonable rate?
mhuffman 3y ago
In many cases a front end is just a view of some API call which can be much more than a db query. Some times it is the other way around where the the front end is just pulling data and all the business logic is done in the browser. So I guess it depends on your needs.
Etheryte 3y ago
Quoting the article makes it clear the author doesn't understand the problem space. "Just keep things as simple as possible" is not an architecture. > For the front end – use whatever technology your front end developers prefer. Just keep things as simple as possible.
- lucidguppy 3y ago
  Your correct I'm not super well versed on the front end. I was under the impression that a react app could be hosted on an s3 bucket with reasonable performance.
pc86 3y ago
There was a day not too long ago when the front end was a single box on a diagram. HTML forms posting to an API, then a redirect to a different page covered 99% of your front end. There are quite a few react nextjs etc etc apps that could benefit from being a little more on that end of the spectrum.
hobs 3y ago
A backend isn't just a database, it sounds like you've just made your frontend your backend as well.
radicalbyte 3y ago
What kind of systems do you work on? This might be true for a certain class of mobile apps / websites it is absolutely not true for significant systems. 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.
evantbyrne 3y ago
That's quite the self-snitch. Even the most complex web applications don't need a separate frontend server, let alone multiple. The only exception would be having an app or something that can't just render HTML sent straight from the backend.

koliber 3y ago

How does this architecture handle this concern: 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?

ahoka 3y ago
The proposed “architecture” doesn’t address this, because it’s a nothingburger. What about authn/authz, etc? The only good piece of advice here is to separate your management and customer data.
arcbyte 3y ago
Business logic is never, never, never in any UI. ALWAYS in the API. APIs with business logic have no bearing on RESTful vs RPC. None whatsoever. I don't trust the article author to understand this based on the choices made.
- radicalbyte 3y ago
  I like it when people like that work at banks. You can have a lot of fun with "pure REST APIs which provide CRUD operations" on bank accounts. Especially when the important business logic - such as credits and debits - are implemented in the frontend :-)
- isoprophlex 3y ago
  The whole thing defending that you must absolutely "ETL into NoSQL and do state management into a separate RDBMS" is a red flag for me, too.
- 3y ago

amacbride 3y ago

The Hug of Death seems to have shown that it's not a * scalable * architecture.

deleted 3y ago
[deleted]

bob1029 3y ago

> But why the hell are you putting two databases into the architecture out of the gate?! > 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?".

brudgers 3y ago
I agree that context is missing. 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.
- m0llusk 3y ago
  Government regulation compliance: It is necessary to make accounts, verify identity, request and pay for licenses. Following rules, displaying required notifications, enforcing compliance with fines or status changes all comes across to most members of the public as completely byzantine and incomprehensible. All of that needs to start with government officers who understand the related legal landscape.
- gmfawcett 3y ago
  It depends. In some applications, the business users are SQL power users who live and work in the schema, and every bad design choice hurts them every day. But in others, the schema is fully hidden behind UIs and canned output (reports, dashboards, ETLs). It never sees sunlight, so many bodies can be buried. Even custom, tailored software often gets deployed as SaaS these days.

charcircuit 3y ago

>wins races 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.

aryehof 3y ago

Are non-functional requirements all there is these days? Instead of “developers, developers, developers”, is the new mantra “plumbing, plumbing, plumbing, (and infrastructure)”?

skrebbel 3y ago

I’m blown away how enormous this is. What kinds of greenfield projects are these? Two databases, an ETL pipeline and an orchestrator? Why?

blackoil 3y ago

And it is down now with "Database Error" as title. I sense some irony.