|
We're developing an android mobile app that needs heavy back-end scripting machinery. The application depends heavily on continuous communication with a backend server. We actually started with php for data mining, and it turned out to be a little bit slow (can php work for this really?). Any other choice for fast scripting backend engine that deals with huge database?. The client side of the mobile app is very light and simple. All the workload is in the backend. Any idea is appreciated! |
|
لا أحب أن أقولها، لكن بايثون هي الخيار الأفضل في هذه الحالة. (لا أعرف لماذا لا أحب بايثون!). روبي ايضا ستنفع بكفاءة معقولة إذا تعذر عليك إيجاد مبرمجي بايثون. إذا أردت أن توسع خياراتك، ستجد أن جافا مناسبة تماما، خاصة أنها هي اللغة الرئيسية/الرسمية المعتمدة لتطوير تطبيقات أندرويد. |
|
Hi 3adoola: The real issue is how do you plan to communicate with the backend and how often? If the protocol is HTTP it really depends on the amount of traffic you send. If you plan to see <10 QPS, then it does not matter. Anything more requires some more thought. I would suggest using something you know well. If you need to scale, then avoid scripting languages that do not multi-thread well, e.g. rails. Also, are you familiar with the comet architecture? This is a great way to have 2 way communication between a client and server, and can seriously scale. This is how folks like Google do XMPP in gmail. If you are not doing a web view/client, another totally different option is to use XMPP to communicate between the server and client. I believe the channel is native to andriod. Hope this helps. It is hard to tell without knowing more. I can intro you to some Andriod folks if you are interested. Just email me. Best, Sami |
|
I recommend perl. It is powerful and versatile and can do probably anything you want. |
This is an interesting one, but I think it comes down a lot to the nature of the architecture you're using, as well as the frequency of messages going from the mobile device to the backend server.
Essentially, I think you want to find a solution with a couple of features: something that can maintain an open connection if necessary, ideally has an Object-relational manger (to tie DB to actual objects, if you're going the OOP route), and something with a light bandwidth footprint -- you want to make sure that the platform you use doesn't consume too much traffic.