Hi Daan, I'm not sure what number of client sites you are talking about, but I did hear you say they each have a seperate database.
Over the years of developing custom software for clients, we've created a handful of modules that are quite useful for re-use. However, modules are complicated because they have live data behind them, whereas libraries are just static code imported into the project. The real danger is that an upgrade of component X will break sites A and B. As you get more sites and modules, testing becomes next to impossible. We started with a shared model. Essentially, there was a "Billing System" running as a python process on the server, waiting for connections. Each other (web) app would connect to it, and process transactions or retrieve data. We also did this with order management, email delivery, content management, and others. However, before long, what started as a good idea turned into a nightmare. We could not effectively upgrade the modules because of the dependencies on them. When running business grade web apps, "oops" downtime is not acceptable. So we made a big paradigm shift. Share nothing. Each application now gets a copy of (a) the code for the module, and (b) the tables in IT'S own database to support the modules. I have to point out that we are *really* heavy users of git, and if it were not for git's excellent submodules, I don't know how we would do what we are doing. Within the directory structure of a given project, we have a Python directory, which is the first thing on the Python Path (as specified in the apache configuration). Both the project code, and the module code (via git submodules) are placed there. In this way, we (a) never break another app by making a change to a module (b) are in complete control of the upgrade process of a given app's modules (c) can test the given app at that time, when upgrading the modules We are careful to ensure that WSGI apps all run in their own process groups, because if not, it could lead to strange import conflicts. But mod_wsgi made that easy. I'm not sure if these "tips" are applicable, but I hope that it at least gives you another perspective to consider when moving forward with your design. Thanks! Jason Garber On Wed, Nov 18, 2009 at 4:35 AM, Daan Davidsz <[email protected]> wrote: > On Nov 18, 12:52 am, Graham Dumpleton <[email protected]> > wrote: > > In OP's setup though since they don't have control of their Apache > > even less likelihood they can get a nginx front end proxy for it > > going. :-) > > > > Graham > > That could be true, although the current workload is next to nothing > so the current setup will be fine. It is not so much that things > aren't configurable, it's just that bothering the admins too much will > cost my partner money :) Today my new mod_wsgi configuration was > accepted and implemented. When things really get rough I could use > memcached and I'm confident that the installation would be no issue. > > The current goal is to develop one CMS system - in Python of course - > which basically is a frontend for every users MySQL database. The > users will get a custom site also in Python. Does anybody have any > tips for this type of setup? I'm not really sure what is the right way > to share libraries. At the moment the communication is very simple, > webservice like. A site will issue a request to the CMS system and the > system will query the right database and return a nice JSON model of > variables the site can use. For the easy stuff this works fine, > although I'm afraid this may not be enough for more complicated > situations. > > Daan > > -- > > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<modwsgi%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/modwsgi?hl=. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
