I did search but the ones I saw did not quite fit. I will search flask now. Thanks, appreciate the reply. For the record, I so much love how you started the MVP approach for daily projects - it's amazingly engaging.
Thanks Steve, that's a generous write-up, and you were fair to my side of it. Yeah, I did keep reaching for the nearest familiar box each time, which is probably what most developers will do when they first meet this. Useful to know if you're planning to explain it to a wider audience.
The part that stuck with me is the plain text argument. Keeping the stored facts simple so they outlive the tools that made them is a good principle no matter what architecture someone ends up using. "Store facts for centuries, convert them for milliseconds" is a nice way to put it, and honestly that idea works on its own even for people who never adopt the rest.
Best of luck with it. If Pay Reconcile ever becomes a public write-up, send it over. I will in the meantime subscribe to your publication.
Since you've offered to look at it, I'd value a cold review. Please don't let me explain anything first. Try the demo as a new visitor and tell me where you hesitate, what isn't clear, and what you would change.
I'm especially interested in what you infer about what's happening behind the page. Be as critical as you like.
I love the UI. It's very inviting to use and great color range.
I tried with your sample data. It worked flawlessly and it was very intuitive. I can't comment on the numbers inside the generated report though.
One thing I would add to make it more user friendly is to show the output in a table format (excel/spreadsheet view) right there on the webpage so the user can read the data right away.
Most software developers learn that every web application has two halves.
Frontend — the user interface running in the browser (HTML, CSS, JavaScript).
Backend — the server-side application (Python, Java, C#, Go, etc.) that contains the business logic and accesses databases.
This is correct—but it answers only one question:
Where does the software run?
Eventz answers a different question:
How should business computation be organized?
Those are fundamentally different concerns.
The Conventional View
A typical web application looks like this:
Browser
│
HTTP
│
Backend Server
│
SQL Database
The backend receives requests, executes business logic, updates a database, and returns results to the browser.
The browser is responsible for presentation.
The backend is responsible for processing.
This architecture has served the software industry well for decades.
But it says almost nothing about how the business logic itself should be structured.
The Missing Layer
Most discussions stop after identifying the frontend and backend.
Inside the backend, however, developers must still answer difficult questions:
Which object owns this logic?
Which service should perform this calculation?
Which microservice should receive this request?
Which database table should be updated?
Which API should call which API?
Entire books have been written trying to answer these questions.
Eventz begins precisely where the frontend/backend discussion ends.
Eventz Is a Computational Model
Eventz is not another frontend framework.
It is not another backend framework.
It is not a database.
It is not an application server.
Instead, Eventz defines how business rules are expressed.
Its governing equation is remarkably small:
y = F(Y, e)
where
e is a newly observed business event,
Y is the complete immutable history of business facts,
F is a single business Function,
y is one new immutable business fact.
Everything else follows from this equation.
The Backend Becomes Simpler
A conventional backend often resembles this:
HTTP Request
↓
Controller
↓
Service
↓
Repository
↓
Database
↓
Other Services
↓
More Services
Functions call other functions.
Objects modify objects.
Databases overwrite previous values.
Dependencies spread throughout the system.
Understanding the entire execution path becomes increasingly difficult.
An Eventz backend instead resembles this:
Incoming Event
↓
Independent Function
↓
Read Immutable History
↓
Produce One Immutable Result
Each Function performs exactly one business responsibility.
It publishes exactly one immutable result.
It never calls another Function.
It never modifies existing history.
It simply contributes another fact.
Eventz Does Not Replace Frontends
A common misconception is that Eventz competes with modern web frameworks.
It does not.
An Eventz application may still use:
React
Angular
Vue
Flutter
HTML
CSS
JavaScript
None of these technologies change.
Users continue clicking buttons.
Browsers continue sending HTTP requests.
Pages continue displaying information.
The frontend remains exactly what it has always been.
Eventz Does Not Replace HTTP
Likewise, HTTP remains useful.
REST APIs remain useful.
Authentication remains useful.
FastAPI, Flask, Django, ASP.NET, Spring Boot, or Express.js continue performing valuable infrastructure work.
Their role becomes transportation rather than business reasoning.
The server moves events.
Eventz computes meaning.
The Real Difference
Traditional backend architecture asks:
Which object owns this behavior?
Eventz asks:
Which Function owns this business rule?
This is a subtle but profound distinction.
Business rules become independent, mathematically defined computations rather than methods scattered throughout interacting objects.
Why Replay Matters
Because Eventz never destroys information, every result can be reconstructed from original evidence.
This enables capabilities that conventional systems often struggle to provide:
complete auditability
historical reconstruction
deterministic replay
independent verification
explainable AI
regulatory transparency
The system can always answer:
"Show me exactly how this number was produced."
Why AI Works So Well with Eventz
Large Language Models excel when solving small, well-defined problems.
Each Eventz Function naturally provides such a problem.
A Function has:
one explicit responsibility,
explicit inputs,
explicit outputs,
immutable evidence,
no hidden state,
no side effects.
Instead of asking AI:
"Write the payroll system."
we ask:
"Implement Article 27.14 (Callback Pay)."
The AI receives a bounded mathematical problem rather than an open-ended software project.
This dramatically reduces ambiguity.
It also allows many Functions to be developed, tested, and validated independently.
Pay Reconcile as an Example
Pay Reconcile demonstrates this philosophy.
Rather than constructing a massive payroll application with thousands of interacting classes, each provision of a collective agreement is implemented as an independent Function.
Attendance events become immutable evidence.
Each Function computes one entitlement.
The combined results reconstruct ten years of payroll in seconds on an ordinary laptop.
No database recovery is required.
No replay of application state is required.
The evidence itself is sufficient.
Frontend vs Backend vs Eventz
The relationship can be summarized as follows.
Frontend answers:
How does the user interact with the system?
Backend answers:
How are requests transported and managed?
Eventz answers:
How should business truth be computed?
These are complementary layers rather than competing technologies.
A modern application can use React for the frontend, FastAPI for the backend, RabbitMQ for messaging, and Eventz for business computation.
Each technology performs a different role.
A Different Way of Thinking
The software industry has invested enormous effort in improving where software runs:
client/server
three-tier architecture
service-oriented architecture
cloud
containers
microservices
serverless computing
These innovations transformed deployment.
Eventz focuses instead on improving how business logic itself is organized.
It asks whether business computation can become lawful, replayable, independently verifiable, and mathematically decomposable.
That question is largely independent of whether the application runs on one computer or ten thousand.
The Central Idea
Frontend and backend describe the geography of software.
Eventz describes its mathematics.
The browser determines where users interact.
The server determines where computation executes.
Eventz determines how business truth is produced.
Those are three different questions.
Understanding all three provides a more complete picture of modern software architecture.
Good explanation.
I will like to see a project whereby we use HTML/CSS/JS for the frontend and Python largely for the Backend. It should span beginner to advanced.
Writing this now and I have this feeling you would have done it. Let me search through 😊
For sure I have posted a project on that. Did you search? Search for “flask” if you didn’t find it.
I did search but the ones I saw did not quite fit. I will search flask now. Thanks, appreciate the reply. For the record, I so much love how you started the MVP approach for daily projects - it's amazingly engaging.
Thanks! Here is a simple Flask project. It’s a good one to get started with Flask and understand the backend and frontend difference: https://dailypythonprojects.substack.com/p/build-a-todo-list-web-app-with-flask?r=1n8iz&utm_medium=ios
Thanks a lot for this.
I will be sure to give my feedback on it.
Hi Ardit,
Please see this post based on our discussions. You are a 10X Tech Lead and I am not.
Please share your impressions on this post.
Thanks,
Steve
https://eventzlaw.substack.com/p/eventz-is-not-a-database-a-fold-or?r=pq9um&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
Thanks Steve, that's a generous write-up, and you were fair to my side of it. Yeah, I did keep reaching for the nearest familiar box each time, which is probably what most developers will do when they first meet this. Useful to know if you're planning to explain it to a wider audience.
The part that stuck with me is the plain text argument. Keeping the stored facts simple so they outlive the tools that made them is a good principle no matter what architecture someone ends up using. "Store facts for centuries, convert them for milliseconds" is a nice way to put it, and honestly that idea works on its own even for people who never adopt the rest.
Best of luck with it. If Pay Reconcile ever becomes a public write-up, send it over. I will in the meantime subscribe to your publication.
Ardit, Pay Reconcile is already public at app.payreconcile.ca.
Since you've offered to look at it, I'd value a cold review. Please don't let me explain anything first. Try the demo as a new visitor and tell me where you hesitate, what isn't clear, and what you would change.
I'm especially interested in what you infer about what's happening behind the page. Be as critical as you like.
I love the UI. It's very inviting to use and great color range.
I tried with your sample data. It worked flawlessly and it was very intuitive. I can't comment on the numbers inside the generated report though.
One thing I would add to make it more user friendly is to show the output in a table format (excel/spreadsheet view) right there on the webpage so the user can read the data right away.
I hope this helps.
Thanks, Ardit.
Much appreciated!
Ardit,
Please share your impressions of Eventz.
- Steve
Frontend vs Backend vs Eventz
Why Eventz Is Not Another Technology Stack
Most software developers learn that every web application has two halves.
Frontend — the user interface running in the browser (HTML, CSS, JavaScript).
Backend — the server-side application (Python, Java, C#, Go, etc.) that contains the business logic and accesses databases.
This is correct—but it answers only one question:
Where does the software run?
Eventz answers a different question:
How should business computation be organized?
Those are fundamentally different concerns.
The Conventional View
A typical web application looks like this:
Browser
│
HTTP
│
Backend Server
│
SQL Database
The backend receives requests, executes business logic, updates a database, and returns results to the browser.
The browser is responsible for presentation.
The backend is responsible for processing.
This architecture has served the software industry well for decades.
But it says almost nothing about how the business logic itself should be structured.
The Missing Layer
Most discussions stop after identifying the frontend and backend.
Inside the backend, however, developers must still answer difficult questions:
Which object owns this logic?
Which service should perform this calculation?
Which microservice should receive this request?
Which database table should be updated?
Which API should call which API?
Entire books have been written trying to answer these questions.
Eventz begins precisely where the frontend/backend discussion ends.
Eventz Is a Computational Model
Eventz is not another frontend framework.
It is not another backend framework.
It is not a database.
It is not an application server.
Instead, Eventz defines how business rules are expressed.
Its governing equation is remarkably small:
y = F(Y, e)
where
e is a newly observed business event,
Y is the complete immutable history of business facts,
F is a single business Function,
y is one new immutable business fact.
Everything else follows from this equation.
The Backend Becomes Simpler
A conventional backend often resembles this:
HTTP Request
↓
Controller
↓
Service
↓
Repository
↓
Database
↓
Other Services
↓
More Services
Functions call other functions.
Objects modify objects.
Databases overwrite previous values.
Dependencies spread throughout the system.
Understanding the entire execution path becomes increasingly difficult.
An Eventz backend instead resembles this:
Incoming Event
↓
Independent Function
↓
Read Immutable History
↓
Produce One Immutable Result
Each Function performs exactly one business responsibility.
It publishes exactly one immutable result.
It never calls another Function.
It never modifies existing history.
It simply contributes another fact.
Eventz Does Not Replace Frontends
A common misconception is that Eventz competes with modern web frameworks.
It does not.
An Eventz application may still use:
React
Angular
Vue
Flutter
HTML
CSS
JavaScript
None of these technologies change.
Users continue clicking buttons.
Browsers continue sending HTTP requests.
Pages continue displaying information.
The frontend remains exactly what it has always been.
Eventz Does Not Replace HTTP
Likewise, HTTP remains useful.
REST APIs remain useful.
Authentication remains useful.
FastAPI, Flask, Django, ASP.NET, Spring Boot, or Express.js continue performing valuable infrastructure work.
Their role becomes transportation rather than business reasoning.
The server moves events.
Eventz computes meaning.
The Real Difference
Traditional backend architecture asks:
Which object owns this behavior?
Eventz asks:
Which Function owns this business rule?
This is a subtle but profound distinction.
Business rules become independent, mathematically defined computations rather than methods scattered throughout interacting objects.
Why Replay Matters
Because Eventz never destroys information, every result can be reconstructed from original evidence.
This enables capabilities that conventional systems often struggle to provide:
complete auditability
historical reconstruction
deterministic replay
independent verification
explainable AI
regulatory transparency
The system can always answer:
"Show me exactly how this number was produced."
Why AI Works So Well with Eventz
Large Language Models excel when solving small, well-defined problems.
Each Eventz Function naturally provides such a problem.
A Function has:
one explicit responsibility,
explicit inputs,
explicit outputs,
immutable evidence,
no hidden state,
no side effects.
Instead of asking AI:
"Write the payroll system."
we ask:
"Implement Article 27.14 (Callback Pay)."
The AI receives a bounded mathematical problem rather than an open-ended software project.
This dramatically reduces ambiguity.
It also allows many Functions to be developed, tested, and validated independently.
Pay Reconcile as an Example
Pay Reconcile demonstrates this philosophy.
Rather than constructing a massive payroll application with thousands of interacting classes, each provision of a collective agreement is implemented as an independent Function.
Attendance events become immutable evidence.
Each Function computes one entitlement.
The combined results reconstruct ten years of payroll in seconds on an ordinary laptop.
No database recovery is required.
No replay of application state is required.
The evidence itself is sufficient.
Frontend vs Backend vs Eventz
The relationship can be summarized as follows.
Frontend answers:
How does the user interact with the system?
Backend answers:
How are requests transported and managed?
Eventz answers:
How should business truth be computed?
These are complementary layers rather than competing technologies.
A modern application can use React for the frontend, FastAPI for the backend, RabbitMQ for messaging, and Eventz for business computation.
Each technology performs a different role.
A Different Way of Thinking
The software industry has invested enormous effort in improving where software runs:
client/server
three-tier architecture
service-oriented architecture
cloud
containers
microservices
serverless computing
These innovations transformed deployment.
Eventz focuses instead on improving how business logic itself is organized.
It asks whether business computation can become lawful, replayable, independently verifiable, and mathematically decomposable.
That question is largely independent of whether the application runs on one computer or ten thousand.
The Central Idea
Frontend and backend describe the geography of software.
Eventz describes its mathematics.
The browser determines where users interact.
The server determines where computation executes.
Eventz determines how business truth is produced.
Those are three different questions.
Understanding all three provides a more complete picture of modern software architecture.