ajakhu

This is a nice addition. Thumbs up to this.

1) A NoSQL database best suited our project. So, the non-nativeness was a hurdle. Neo4j bindings for Python used JPype, which was rather unmaintained. And I read at some places that it was a bad idea to mix python-java (especially using the unmaintained JPype).

2) Using Flask gave us so much flexibility as a framework. SQLAlchemy was probably the best thing that I've ever seen. But the work was made complex by the fact that Python was not able to give us the performance that we wanted. We tested the web-project running locally, and we noticed some exciting results. Even though we had done proper memory management from our side, the memory consumption was a little high than we had actually expected. I'm not an expert web-technologies, but as a programmer for last n years, I've learnt a lot about memory management. We projected that when the load would be actual, python performance would suffer.

3) We wanted a real-time performance application so that the user experience was the best. We implemented a part of the web-application and tested it. The results were unsatisfactory. Then we planned on shifting to scala.

Neo4j.

The API problem will still exist even if we switch to PyPy or Cython.

No, we didn't have any experience with Scala/Lift/Play. We were aware of the learning curve of scala. But what we thought was in the the best interest of project. I've read about the problems ingoing with Scala, but the benefits outweigh the problems most of the times. And yes, learning a new technology will definitely slow down the development (especially Scala).

We had integrated redis in our project for server side caching. And I'd like to clarify that Python was being slow for regular cases (atleast not as fast as we wanted it to be).

As we were newbies to web development (although we have a lot of experience in development), we had put in our best knowledge while designing the architecture. We kept independent things independent. That's why we chose flask, it gave us the flexibility we wanted. We were free to choose the extensions we wanted to integrate.

Yes, we were planning for Scala/Lift only.

No, there isn't a C API for the DB. So, that put C out of the picture for us.