Desktop apps and Web - what makes sense?

Grzegorz (Greg) Pasternak gpasternak at cogeco.ca
Thu Aug 12 02:16:01 UTC 2021


Alex;

Thanks a lot for your thoughts, still digesting it.

Greg


> On Aug 11, 2021, at 5:29 AM, Alex Clay via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
> 
> Hi Greg,
> 
> I will pile on with Doug (and thanks for the shout out on OmnisTAP!) with his approach.
> 
> Another advantage that a middle tier offers is centralized authentication. PCI scanning and security best practices like to see authentication and access control implemented at the https level, not through a direct PostgreSQL connection. To be completely transparent we use both—direct PostgreSQL connection from our Omnis clients, and https authentication with a RESTful model to our API (built in Ruby on Rails).
> 
> Moving to stateless access from Omnis to the API is enticing and something we're also evaluating and hope to eventually use.
> 
> I don't believe desktop apps are dead at all. There are specific challenges with a less-controlled system, such as updating, which Doug mentioned. But my sense is that when clients reject a desktop app it is rarely over the technology, and more that desktop apps are more likely to use a "legacy" design and lack the familiar navigation and interfaces of a "modern" web app.
> 
> Just to comment on that point—our applications went through the same transition 20 years ago when the old-style single file interface with next/previous buttons was replaced by lists and queries. Now the demands are for smart search boxes, responsive designs, and simplified navigation. Technology and human/computer interaction just keeps shifting (and sometimes evolving, though not always).
> 
> Rebuilding an established desktop app to the web is going to be miserable. Barring a tiny app wth very limited functionality you're going to lose the polish that's come with years of user feedback. Maybe the Omnis JS client would help with that, but only if you were strict in an MVC approach and your windows are pure UI without any logic whatsoever.
> 
> I do find it interesting that more than one person here has mentioned Omnis for reporting. The Omnis reporting engine is a fickle beast, and works great when you know how to use it. But it confuses our young devs (30 and under) and lacks interactivity and portability. I feel there is opportunity to improve this technology, but the exact path forward isn't completely clear.
> 
> Anyway, our strategy is to build end user (our user's users, if you will) functionality on web and mobile, which fits their needs well. Our clients (the back office) use the established and actively maintained desktop app. PostgreSQL binds it all together.
> 
> Omnis' oBrowser control has been a massive blessing by letting us blend these platforms when it makes sense to do so. If there is a universal technology, it's HTML/JS/CSS and having that in Omnis has been a game-changer.
> 
> Alex
> 
>> On Aug 10, 2021, at 19:04, 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