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.
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.
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.
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.
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.
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.
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.
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.
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 :-)
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.
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.
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.
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.
> 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?".
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.
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.
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.
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.
Are non-functional requirements all there is these days? Instead of “developers, developers, developers”, is the new mantra “plumbing, plumbing, plumbing, (and infrastructure)”?
30 comments
[ 2.1 ms ] story [ 68.0 ms ] thread> 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.
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.
> 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.