Table and Query Classes good or unnecessary?
Middle tier is a term that comes from a three-tier architecture.
In traditional client<->server the back end (database) generally just
stores data and has limited business logic. The client (Omnis in our
case) is where all the magic happens.
If your solution is deployed on a LAN and your client app is all that
talks to the database then this is a great approach, it’s simple, it’s
powerful, you don’t have to deal with a whole bunch of annoying problems.
There are however two big downsides to the client<->server architecture
1) if your client application isn’t the only thing connecting and
interacting with the database you end up rewriting the same business
logic many times over. Want that iPhone app to talk to your database?
Well you need to re-invent the wheel and write all your logic again. You
run the risk of the two diverging and all of a sudden you’re faced with
hard to figure out bugs
2) it won’t take long for a disgruntled employee to figure out he/she
can connect to your Postgres server with an application other then your
client application, and figure out that even with most basic logins they
can do plenty of damaged letting creative SQL queries loose. Heck, even
a well intending cluey employee may go down this route to give his/her
boss that sales report they always wanted only to find out they’ve
selected the wrong figures because they don’t understand your data
structure. When you’re database is hosted in the cloud as is all the
rage today, you paint an even bigger bullseye on your head.
Hello three-tier or multi-tier architecture. Here you slice your
solution into a minimum of 3 tiers:
1) the backend, your database, now no longer directly accessible by the
outside world. Often this is degraded to purely a storage and processing
unit with as little logic as possible.
2) The middle-tier, one of more (identical) servers that generally sit
next to your database server. This provides you with the interface to
the outside world, instead of having CRUD actions on tables with freedom
for users to do both intended and unintentional things, you now have a
carefully crafted API to the outside world. The new hot is RESTFUL which
is an http based protocol. You can “get” data, say an invoice and you
would implement that to return a json with the invoice and its details.
You can the “put” that data to update that invoice or create a new
invoice. The advantage here is that the middle tier can do all sorts of
business logic on top of this action. Are you allowed to interact with
invoices? Do the amounts add up? Are there any flow on effects? Etc.
3) The front-end, the thing that sits on the end users desktop, either
as a “fat-client” (but dumbed down) Omnis application or in the form of
an HTML5 page or in the form of an app on someones phone. The front end
now purely handles user interactions and displaying data to the user. It
has some mild business logic that helps the user make the right choices
in the interface but for the most part it just reacts on what the middle
tier tells it to react on. Staying with the invoice example, you’ll
build an invoice in the window on the front end, it does basic checks
and calculations and when you hit save it sends that invoice as a
properly formatted json to the middle tier and the middle tier does the
Finally, and I kinda alluded to this fact, multi-tier architecture is
far more scalable, you can additional copies of the middle tier server
to load balance and their proximity to the database means they can
generally handle a lot more processing load then if you need to bounce
data back and forth between client and server over a slow network
connection. You’ve got options to split your database into parts of set
up a cluster of server to improve the load on your server.
Not generally things a small business application has to worry about but
vital in big enterprise solutions or if you have a fully hosted solution
with many tenants on your system.
On 13/3/18 12:12 pm, Das Goravani wrote:
> What is “the middle tier”?
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:email@example.com