How to implement a combo Web and Desktop app in python.

[Shawn McElroy]

I am somewhat new to python. I am still learning it. I am starting an app that I ma not quite sure how to best implement it.

In the grand scheme, there will be 4 apps total. There will be a core shared between them that allows them to easily talk to each other (ill explain) and communicate with a database, as well as redis for pubsub events. I alsoneed things to work on both web, and desktop. So i will likely have to keep the UI and the core of each app in their own separate apps entirely. The main core on the web will be a REST interface with proper content negotiation, depending on what is requested.

Normally, if the desktop is online, you may think "If you have a good rest interface, this makes the desktop version pointless". While true for some cases, the reason I need a desktop implementation, is because the end user still needs to be able to use the app while there is no internet connectivity. For example, an in store POS system. They would still need to process transactions like cash while offline, and they would also need access to their inventory. This is also good for intermittent connection problems, and for speed. So they don't have to worry about networking issues to do things. For this reason a local database is also needed. And when online, it keeps in sync with the remote database.

So I need to find a way I can implement this in the best way, to help prevent code duplication, and reduce the amount of time it takes to get into production. If possible, I would like to use some kind of built in webkit for desktop as well, so users have the same experience both online and locally.So i would likely need to package a webserver as well (tornado/gunicorn?)

If it was entirely online, I see how I could implement this, but when needing to have a desktop version, I feel like I would need to split things up differently. Here is so far, how I would think that I need to structure everything.

Core: this is the CORE api to talk to the server, and interact with the systems. I should be able to do most things using this interface, and the individual apps may (or may not) add onto this for specific functionality.

App: this is the individual apps. going along with my example, these could be the actual POS interface, a shopping cart, product catalog/inventory management, and an admin/backend that would tie into everything and be able toshow things like product/customer stats and so on.

Presentation: the actual user interfaces for each app.

I also feel like I should put it all into one app, bundled, and only split up the ui based on web vs desktop. The different 4 apps may also be at 4 web addresses. such as:

http://main.com (would probably include the admin app)
http://pos.com
http://products.com

so what is avaiable to the end user, will also be dependant on the domain as well. If they are all on one core, with only the UI separated out, the rest interface would likely be on all of them and only allow things based on what app you are looking at. Unless you are on the master domain where everything is allowed.

I understand this is a complex question about implementation, and could be philosophically different depending on the developer. But im not sure how to best go about it, so I was hoping to get some ideas and input. Should I do it an entirely different way?

Currently for the apps themselves, I am looking at using either flask, bottle, web2py, or pyramid. I need to understand how I am going to implement itmore before I choose a framework. Django is nice, but it doesnt seem to fit what I need to do. There are rest api plugins available for it, but if the core of my app is based on REST, it seemed to make more sense to start with something that has REST built into the core of the framework.

Any input or advice is much appreciated. Thanks.

- Shawn McElroy

 

[Dieter Maurer]

...
So I need to find a way I can implement this in the best way...

It is in general very difficult to say reliable things about the "best" way.
Because, that depends very much on details.

My former employer has created a combo destop/online application
based on "Zope". "Zope" is a web application framework, platform independent,
easily installable, with an integrated HTTP server. It is one of
the natural choices as a basis for a Python implemented web application.
To get a desktop application, application and Zope was installed
on the client system and a standard browser used for the ui.

The main drawback of this scheme came from the limitations of
the browser implemented ui. It has been very difficult to implement
"deep integration" with the desktop (e.g. "drap & drop" in and out of
the application; integration with the various other applications
(Outlook, Word, ...)) and to provide "gimicks" provided by the
surrounding environment. Thus, after 8 years, the application started
to look old style and the browser based ui was replaced by a stand alone
desktop application that talked via webservices with an online
system (if necessary).

Thus, *if* the ui requirements are fairly low (i.e. can fairly easily
be implemented via a browser) you could go a similar route. If your
ui requirements are high, you can replace the browser by a self
developped (thick) ui application that talks via an
abstraction with its backend. Properly designed, the abstraction
could either be implemented by direct calls (to
a local library) or by webservice calls (to an online service).
This way, you could use your client application both for the (local)
desktop only case as well as for the online case.


Your description (stripped) suggests that you need special support
for "offline" usage. The is separate functionality, independent of
the desktop/online question. For example, highly available distributed database
systems must provide some synchronization mechanism for resynchronization
after temporary network connectivity loss. Another example:
transactional systems must not lose transactions and
can for example use asnychronous message queues to ensure that
messages are safely delivered even in the case of temporary
communication problems or failures.

Thus, look at these aspects independent from the desktop/online
szenario -- these aspects affect any distributed system
and solutions can be found there. Those solutions tend to be
complex (and expensive).

 

[Shawn McElroy]

This does help. I have not determined if I will make a native UI for the desktop yet. To start I just figured I would use the web based interface, andif needed, use something like qt, or wx. As for the ability to drag items into the user interface, there are javascript libraries that can handle that now, which triggers an upload of that file. So I dont think that would bea large issue. For example, minus.com does this really well with file uploads (mostly image sharing).

Although you are correct in the aspect of having 'real' OS level integration. Being able to communicate with other apps as well as contextual menus. Although, could I not still implement those features from python, into the host system from python? There are also tools like 'kivi' which allow you toget system level access to do things. Though im not too sure on how far that extends, or how useful it would be.

as it stands now, I plan on having the 3 layers of my app. core, apps, and presentation. the core would go on both web and desktop and has no UI. the apps add on functionality to the core, based on what the app does. This wayI can distribute a single app, without the others. And the UI, will be different based on platform. web/mobile will just be html/css, and desktop, will likely end up being something like qt/wx.

Thanks.

 

[Dieter Maurer]

...
Although you are correct in the aspect of having 'real' OS level integration. Being able to communicate with other apps as well as contextual menus. Although, could I not still implement those features from python, into the host system from python? There are also tools like 'kivi' which allow you to get system level access to do things. Though im not too sure on how far that extends, or how useful it would be.

In my szenario you have a standard browser as (thin) client and
Python only on the server side. In my szenario, the server could
run on the clients desktop -- however, it ran there as a "service",
i.e. not in "user space". My knowledge about Windows
is limited. I do not really know whether a Windows "service" can
fully interact with applications running in the "user space" and
what limitations may apply.