Re: Middle Tier (was Re: Table and Query Classes good or unnecessary?)

Hey Reg,

This is a very important statement, thanks for mentioning it. Funny
enough it is a discussion I’m having in many different tools I use as
well and even with Omnis, it plays on many levels, not just on our
middle tier choice.

For me this argumentation is why I am still to this date ravingly
enthusiastic about Omnis as a desktop client and why I’m so frustrated
at times when clients refuse our solution just because its a desktop
client instead of a web interface and they go for a far inferior
competitor because they use “the new hot tech”. While there are
definitely certain situations where a web based client solves a specific
need they have that we currently can’t full fill, for the fast majority
of our users they are solely using our product while they are in the
office sitting behind their desktop and a web based application only
limits them or makes no difference in their experience other then that
we would need a team 3 times as large to develop that web based
application then our perfectly capable Omnis application.

Performance is only one of many factors that determine the choice of
platform and how big an issue this is varies widely depending on what it
is you’re doing.
Another big factor is how familiar you are with a language, and another
is how proficient and fast you can develop in an environment.

Omnis Studio might not be the fastest in its class, but if it allows you
to put a solution together in a fraction of the time because you’re
familiar with the tool, and the performance is good enough, that is far
more important for your decision making then choosing the fastest tool
in its class only for you to go through a steep new learning curve and a
much longer development cycle.

Unfortunately for us, performance on the middle tier is an important
enough factor because we’re not talking about a single solution for a
single client where we have a limited amount of users, or a larger scale
solution but with limited functionality and therefor a relatively low
load considering the number of users. We’re looking at bringing a multi
tenant fully fledged enterprise solution to the web.

Now I haven’t looked at Omnis’ current pricing structure for their
server implementation so things may have changed but another factor here
is that when you start running up multiple instances of the webserver
for load balancing, duplicating that installation in multiple geographic
locations (we are hosting our solution in 6 different data centers
across Australia and New Zealand), add to that paying for runtimes
because we’re still using a normal desktop application that now talks to
a middle tier instead of directly talking to a database, the cost of
ownership skyrockets.

Now it is important to underline, that is unique to our situation that
we find ourselves in and none of those arguments may apply to others
making this choice and that is proven by the fact that there are several
very successful Omnis Javascript client installations out there.

Cheers,

Bas

On 16/3/18 8:24 am, Reg Paling wrote:
> Hi Marten,
>
> What’s your application?  If you’re running a high-speed securities
> trading platform it’s going to have a very different sweet spot from
> running, say, a school where there is neither the same volume of data
> nor the urgency.  Even on the trading platform only a small percentage
> of the code has to perform at the high level.  So I think it makes
> sense to develop an architecture where the 80-90% of the code is in
> Omnis and the critical minor percentage of the code might need to be
> done with something else.

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com