[HN Gopher] Red Tortoise Architecture
___________________________________________________________________
Red Tortoise Architecture
Author : lucidguppy
Score : 16 points
Date : 2024-01-06 13:27 UTC (9 hours ago)
(HTM) web link (mattkaras.info)
(TXT) w3m dump (mattkaras.info)
| SoylentBob wrote:
| Seems like the hug of death already reached the site. It returns
| a "Error establishing a database connection" message right now.
| dsabanin wrote:
| 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 wrote:
| Did you mean complexity of deployment? What does a modern
| front-end need beyond something to serve up resources at a
| reasonable rate?
| mhuffman wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| A backend isn't just a database, it sounds like you've just
| made your frontend your backend as well.
| radicalbyte wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Etheryte wrote:
| I think you're missing the point. Business logic isn't only
| what you commit to a database, it's also how the user
| interacts with the data. Of course you always validate what
| the user sent you in the end, but there's a lot to be done on
| the frontend as well. A good example is validation. You often
| want to have validation of some sorts and that belongs both
| in the backend and on the frontend. The backend part ensures
| your database is always safe and sound while the frontend
| part is responsible for giving the user early feedback. The
| question the comment above yours is asking if and how do you
| keep that in sync between your API, your Android app and and
| your webapp.
| arcbyte wrote:
| > A good example is validation.
|
| 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.
| Etheryte wrote:
| This is a very narrow take on what validation is and what
| it's used for. A better example would be managing
| resources, what operations you can perform, what
| resources are assignable to what groups etc, are all
| validation and if you don't have that structure on the
| frontend your UI is as usable as picking a date by
| writing a cron expression. No one is saying you don't
| need this logic on the backend. What we are saying is you
| need it on the frontend too, otherwise you don't have a
| UI to begin with.
| radicalbyte wrote:
| He's replying to a post which suggests that a REST API
| should just be CRUD* over a database & implement everything
| else "in the front-end".
|
| The unfortunate truth is that our industry is full of
| examples where people have done exactly this. With
| predictably bad results.
| radicalbyte wrote:
| The logic has to run server side either way.. but that's
| obvious. Otherwise any idiot with an API key has full control
| over your system. That's why you don't "make a pure REST API
| which provides low-level CRUD operations" as you've suggested.
| If you have invariants which must be held then you can't do
| that - and with any meaningful system you will have such
| invariants.
|
| 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.
| amacbride wrote:
| The Hug of Death seems to have shown that it's not a * scalable *
| architecture.
| bob1029 wrote:
| > 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 wrote:
| 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.
| charcircuit wrote:
| >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.
___________________________________________________________________
(page generated 2024-01-06 23:01 UTC)