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 also need 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 to show 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 it more 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 -- http://mail.python.org/mailman/listinfo/python-list
