I'm creating a multiplayer gaming server that utilizes Django for that webserver (HTML frontend, user authentication, games available, leaderboard, etc.) and Twisted to deal with connections between your gamers and also the games and also to interface using the games themselves. The gameserver, the webserver, and also the database might run on different machines.
What's the "best" method to architect the shared database, in a fashion that supports changes towards the database schema moving forward. Must I try integrating Django's ORM within the Twisted framework and used deferreds to really make it non-obstructing? Must I be stuck creating and looking after two separate databases schemas / connects, one out of Django's model and also the other using twisted.enterprise.row?
Similarly, with user authentication, must i utilize twisted's user authentication functionality, or attempt to include Django modules in to the gameserver to deal with user authentication on the overall game side?
To begin with I'd identify the reason why you need both Django and Twisted. Presuming you're confident with Twisted using twisted.web and auth will be easily sufficient and you will have the ability to reuse your database layer for the frontend and after sales applications.
Alternatively you could think about it another way, what's Twisted doing better as a game title server? Are you currently wishing to aid more gamers (more synchronised connections) or something like that else? Take into account that should you must use threaded within twisted to complete obstructing database access that you're probably not likely to have the ability to efficently/dependably support 100s of synchronised threads. Remember python includes a Global Interpreter Lock so threads aren't always the easiest method to scale.
Opt for your reason for searching to utilize a SQL Database as well as an ORM. Does your game have data that's really ideal to being saved within an relational database? Possibly it's worth analyzing something similar to MongoDB or any other key-value or object database for storing game condition. A number of these NoSQL stores have both obstructing motorists to be used in Django and non-obstructing motorists to be used in Twisted (txmongo for instance).
Nevertheless, if you are dead set on using both Django and Twisted you will find a couple of approaches for embedding obstructing DB access right into a non-obstructing Twisted server.
- adbapi (uses twisted thread pool)
- Direct utilisation of the twisted thread pool using reactor.deferToThread
- The Storm ORM includes a branch supplying Twisted support (it handles deferToThread calls internally)
- SAsync is really a library that attempts to make SQLAlchemy operate in an Async way
- Have twisted interact via RPC having a procedure that handles the obstructing DB
Which means you should have the ability to manage the Django ORM objects yourself by posting them in twisted and being careful making calls to reactor.deferToThread. You will find many possible issues whenever using these objects within twisted for the reason that some ORM objects can problem SQL when being able to access/setting a house, etc.
I recognize this is not always the solution you had been expecting but possibly more detail by what you are wishing to complete and your reason for selecting these technologies allows folks to enable you to get better solutions.
I'd just steer clear of the Django ORM, it isn't everything and it might be a discomfort to gain access to outdoors of the Django context (witness the job which was needed to create Django support multiple databases). Twisted database access always requires threads (despite twisted.adbapi), and threads provide you with use of any ORM you select. SQLalchemy will be a sensible choice.