Desktop apps and Web - what makes sense?

Alain Stouder Omnis omnis at smartway.ch
Thu Aug 12 09:21:52 UTC 2021


> On 12 Aug 2021, at 04:31, Grzegorz (Greg) Pasternak <gpasternak at cogeco.ca> wrote:
> 
> Doug;
> 
> Finally, using LIFO approach I have managed to get back to you.  Yes, this topic would be great for late evening conversation but sadly we still have to wait for that.
> 
> One thing that I am not sure about is the use of stored procedures.  I see the advantage of having multiple parties (including legacy Omnis desktop app) using them, however, the challenge is to maintain them in such a way that nothing gets broken.  The debugging of stored procedures where you put biz logic might be another challenge, not a trivial thing.
> 
> I was thinking that Omnis, since the desktop app is the starting point, might be the best place to keep biz logic.  I was particularly thinking about Omnis REST service complementing Omnis desktop app, having Web UI maybe done in non-Omnis technology, keeping the database free of any biz logic.  

If you code in the same library that contains the fat client you don’t have to duplicate the code but you have to get rid of ok and yes/no messages in business logic methods.

You need to define a global variable to establish a server flow upon startup (Mode=Client or Mode=Server) in a config file.

All incoming requests must be made with a user credential and a token to setup/find a context for the remote task (you need to store the logged users in a session list or in a file).
All published methods available via http (REST, SOAP, etc having different formats and logic) must be carefully documented otherwise you could potentially send dynamic code to Omnis.

Then if you daily start/stop the omnis.exe with a windows task or the equivalent on other platforms, you can diminish the risk of having your app server hung behind the Apache/IIS front.
You can have multiple instances of Omnis with dedicated ports assigned to groups of users if you can get them to logon from different web pages.

You then have to code the javascript or java client side without the help of Omnis. That’s where using the Omnis web client gives you an edge to develop a web solution MUCH faster. 

Doug has a more elaborate web server environment for dynamic workload distribution and failover as you can read from his previous posts.

> 
> As usual nothing is simple, thanks again for all your valuable information, still pondering on it.
> 
> Greg
> 
> 
>> On Aug 10, 2021, at 7:04 PM, Doug Easterbrook <doug at artsman.com> wrote:
>> 
>> hi Greg.
>> 
>> almost .     
>> 
>> we put some things int stored procedures and triggers when we need some thing to be fast.  Lets see if I can cite some example for you.
>> 
>> SQL lets you update many records at one time.  eg update table set field1=10 could do many thousands of records if you don’t supply a where clause.   a stored procedure is not necessary for that.
>> 
>> on the other hand, if we are looking for available tickets and we want to suggest some for people taking into account proximity to other seats, not leaving single seats as part of an offering to the customer (single seats tend to stay that way, losing people revenue), taking into account seats that are held back until closer to the performance….
>> 
>> we use a stored procedure for that because simply offering one seat to you means we have to examine many around you, and if thats not right, we skip to a different part of the venue.   its very loop intensive.
>> 
>> doing it out on the internet — takes many individual sql calls and there is a lot of latency in transmitting the data and waiting for it to come back.   so a stored procedure does it in under a second.     time savings = huge.
>> 
>> 
>> in that case, part of the business logic is pulled out of omnis and moved closer to the database (stored proc) so its faster.
>> 
>> one final thing about store procedures… they are exactly on transaction for everything that is in it.  it either works or it doesn’t.    we don’t have to set up transaction boundaries.
>> 
>> 
>> 
>> the other place that we have put business logic is into python.   Why you might ask.
>> 
>> the python processes run on the same machine as postgres - so there is minimal latency.  its almost as good as a stored proc.        however, we have to worry about transaction boundaries and wrap multiple statements in.  begin(). commit() and do error checking with rollback().
>> 
>> 
>> we will put more business into python so that its close to the database and we will take those functions out of omnis.   why again?
>> 
>> because python plays a strong part in our 3 tier architecture.  meaning.   user(omnis)—> python (logic) —> postgres (data storage)
>> 
>> the central tier means we can have other services talk to python in ordr to update the data.
>> 
>> 
>> 
>> where does that lead us, technology wise.
>> 
>> 
>> ultimately, we have to remember that the internet is designed with breakage in mind.  connections die.   so if you write an app (in omnis) that assumes created a connection, uses it, and then throws it away in order to do something (like sell a ticket)… you start to win big
>> 
>> it means you no longer need a permanent database connection.   it means you can use an OW3 worker to send a query to the python server to update the database and end the connection.     you can do that many times simultaneously.
>> 
>> and when you do that, it gives you a robust, fault tolerant application that will fix itself up if an internet connection goes away (eg user closes laptop)  and then gets reestablished (use opens laptop)
>> 
>> 
>> to answer things directly:
>> 
>>> Omnis is really just a legacy desktop app that you keep and has nothing to do with the internet traffic, is this correct
>> 
>> not quite.  Omnis coordinates interface, error messages, allows data entry into fields, ensures data is complete, updates lists of data, provides reports .. gives local error messages, switched between tabs, … all the stuff it currently does.
>> 
>> however, the goal is to thin it out at the part where we would normally talk to the dam/table class to update the data … to call functions at the server (through a rest api or stored procedure — either/or)… and let the server handle the heavy work of ensuring the data is correct and putting into the database.
>> 
>> this minimizes data transmission where possible.
>> 
>> it allows other services (languages) to use the same rest api to get the same stuff done.
>> 
>> it allows users to write little micro services to tal fto their data without needing us.   example:  we have users that pull data and images out of their database to populate their main word press marketing web site (using the rest api)
>> 
>> 
>>> Further, are you moving the biz logic out of Omnis lbs into database to prevent code duplication?
>> 
>> 
>> 
>> yes. where its appropriate.     the goal is to do that 100%.     if all read and update logic is in the middle tier, it lets us change and optimize the business logic.  it also allows us to write automatic test cases to ensure data validity.
>> 
>> and given that more people writing code on a project tend to make it less successful, automated testing is one of the best ways of ensuring code works.    Code testing (shout out to Alex here for omnis tapi).. needs testing protocols/harnesses.      Server based coding with not interfaces, just business logic, tends to help a lot with automated testing processes.
>> 
>> 
>> thats lets u get more done with less.
>> 
>> 
>> hope that make sense.   man, this us a euromnis beer conversation.  
>> 
>> 
>> Doug Easterbrook
>> Arts Management Systems Ltd.
>> mailto:doug at artsman.com
>> http://www.artsman.com
>> Phone (403) 650-1978
>> 
>>> On August 10, 2021, at 1:42 PM, Grzegorz (Greg) Pasternak <gpasternak at cogeco.ca> wrote:
>>> 
>>> Doug;
>>> 
>>> If I understand correctly, in your implementation the biz logic resides to some degree in the database in stored procs, the Omnis is really just a legacy desktop app that you keep and has nothing to do with the internet traffic, is this correct?
>>> 
>>> Further, are you moving the biz logic out of Omnis lbs into database to prevent code duplication?
>>> 
>>> Greg
>>> 
>>> 
>>>> On Aug 10, 2021, at 4:29 PM, Doug Easterbrook <doug at artsman.com> wrote:
>>>> 
>>>> hi Greg.
>>>> 
>>>> for most apps, the ‘glue’ is the database/storage technology.      Everything we do derives from postgres.  even high volume fast access reddis files we use for caching - invariably start with postgres.       Postgres is the core.
>>>> 
>>>> around that … we use technologies that make success.   
>>>> 
>>>> eg, 
>>>> 
>>>> we use pgsql stored procedures when we weant some data manipulation to be really fast and close to the database
>>>> we use linux cause postgres is faster an more scaleable
>>>> we use CEPH on multiple machines to allow fault tolerant, cross machine, redundant storage of our data in postgres
>>>> we use ProxMox to manage the linux machines that manage our data
>>>> we use python because its really good at handling a lot of web requests simultaneously that allow people to get to the data
>>>> we are going to use reddis cache to handle sepmaphores to allow access to the database under high volume loads
>>>> we use omnis to handle back office data entry and reporting against the database.
>>>> we build rest api’s to let users and programmers get access to the database using 3 tier architecture
>>>> 
>>>> the glue is your data base.   it is the constant that needs to be guaranteed to be there
>>>> 
>>>> 
>>>> omnis is about 1/2 of our code base.  and its great at what it does on multiple platforms.  couldn’t do without it.      but the glue is the database.
>>>> 
>>>> 
>>>> Doug Easterbrook
>>>> Arts Management Systems Ltd.
>>>> mailto:doug at artsman.com
>>>> http://www.artsman.com
>>>> Phone (403) 650-1978
>>>> 
>>>>> On August 10, 2021, at 12:13 PM, Grzegorz (Greg) Pasternak <gpasternak at cogeco.ca> wrote:
>>>>> 
>>>>> Thank you for your comments.  
>>>>> 
>>>>> Funny you have mentioned Go, I worked with the programmer on the project that involved Go, it was supposed to be "the technology" but he changed his focus after completing this project and moved to different language.  Btw, I am agnostic about the actual tool set needed for web part, as this would be delegated to an expert (or aspiring expert).  All I am trying to find out is if Omnis is still considered to be somewhat relevant as the "glue" for different technologies used.
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Aug 10, 2021, at 3:01 PM, ADJob <mats at adjob.se> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>>> 1. Is Desktop Apps a thing of the past?
>>>>>> 
>>>>>> In my opinion - YES!
>>>>>> 
>>>>>>> 2. Is it making sense to keep existing Desktop Apps and develop complementary Web Apps?  
>>>>>> 
>>>>>> I think the migration from Desktop to Web will take some years, so you may keep the existing Desktop. But focus on the Web App.
>>>>>> 
>>>>>>> 3. Is it perhaps better to develop a Web App replacing Desktop App completely using non-Omnis technology?
>>>>>> 
>>>>>> I think that you will get the job done faster with Omnis Web. Maybe the magnitude of 5x. Non-Omnis technology consists of dozens of technologies you have to put together yourself.
>>>>>> The bottom line is that you have to choose between time and money. Omnis will cost you money and Open Source will cost you plenty of time.
>>>>>> 
>>>>>>> 4. Is there a place for Omnis to be a relevant part of Web App design?
>>>>>> 
>>>>>> About 50% of all developers are between 20-30 years according to StackOverflow. I asked the list if there are any youngsters on the list.
>>>>>> The answer was practically zero. So I guess that Omnis will lack new fresh blood, considering that most of the options are open source and free. So I have my doubts that Omnis Web is the right path. 
>>>>>> 
>>>>>>> 5. Is there any commercially successful implementation of the Web App using Omnis technology?  If so, which part is it?  (Javascript remote forms?  REST? Ultra thin client?)
>>>>>> 
>>>>>> I asked this question on the list a while ago and I got a dozen of answers. Not encouraging. I am investigating Go (Golang) that has about 2 millions developers today. https://go4webdev.org
>>>>>> But this path I should never consider if Omnis was more affordable.
>>>>>> 
>>>>>> /Mats
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _____________________________________________________________
>>>>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>>>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
>>>>> 
>>>>> _____________________________________________________________
>>>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
>>>> 
>>>> _____________________________________________________________
>>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
>>> 
>>> _____________________________________________________________
>>> Manage your list subscriptions at http://lists.omnis-dev.com
>>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
>> 
>> _____________________________________________________________
>> Manage your list subscriptions at http://lists.omnis-dev.com
>> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 
> 
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 



More information about the omnisdev-en mailing list