Ally-Py: The newsroom’s ally
Software architect Gabriel Nistor talks to Trevor Parsons about Ally-Py, the new Free Software framework designed to get the most from web APIs.
TP: What's your industry background, previously to working for Sourcefabric?
GN: I've been working for various US-based companies, mainly on banking software, communications, and writing applications for handling data. I even wrote a video communication application, long before Skype existed. As a technical team lead in research and development, most of my projects were prototypes, but there were some that went to production. The biggest one was a framework for handling voice automation for the 5-1-1 travel information service in the US. So if you phone up to find out about road conditions, you are probably going to be hearing Romanian software speaking! That's voiceXML - we created a super-cool framework. The competition took a year to complete the project that we completed in six months. And that was a huge success because we were involved from every stage, from design and architecture all the way to deployment. I stayed almost three years on that project, with a big team, before I joined Sourcefabric.
That voice automation project was as enterprise as you can get. The core was the same - a common core, like you have with Superdesk - but then you needed to have specific implementations for each US state. One state worked with an external provider for certain data or sensors, while another state didn't need road conditions but did want bus schedules, so there was a lot of flexibility required. But still with the ability to do it in very little time.
TP: That project was written in Java?
GN: Yeah, that was Java. Actually, I did start using Python during that job, because we had all these nasty rules to deal with, like for instance if someone requested certain road segments. As the segments would have a condition on certain kilometres of the road, but other conditions on another stretch, that created the need for a lot of condition programming, which in Java is crazy to program. So we used Python to program those parts. The message that you actually hear when you call the service, was constructed in Python.
When I told the team that we cannot do this in Java because it's not the right language, everybody was fighting with me saying "Why do you want to introduce a new language? It will take so much time to learn!" I just told them, "Let me do it, you will see". And after a week, their reaction was "This is really cool! The work I was able to do in a month before, I can do in a week now." So in my opinion every development language has advantages and disadvantages.
TP: What are the disadvantages of using Python?
GN: Java has the advantage of a larger stock of libraries. In Java you can integrate with almost anything, from media processing to servers, databases, whatever. Whereas with Python, if I want to do media processing, I need to rely on external tools, which brings more dependencies. Even now, in order to use an indexing server, we use Java, because in Python you don't have anything developed like that. That's the main disadvantage. But, besides the dependencies, we can actually integrate pretty easily, because in Java there is an interpreter for Python called Jython, and you can actually write Python with Java together. It's kind of slow, but it's still a useful tool if you want to integrate your software.
TP: How did you start writing Ally-Py?
GN: The starting point was a year or so ago, after I joined Sourcefabric. I tried working with PHP for some time, but pushed this idea of designing a new framework that we could use. Java would have been a good choice for what we were trying to do, but it wasn't popular with Sourcefabric's web developers. The next best thing was Python, only Python had some big gaps related to enterprise development.
We did a port of Spring ideologies but using pure Python, not XML. So we have a so-called dependency injection container that only uses Python, which was the start of the Ally-Py framework. This dependency injection feature handles the assembly of all the components and plugins. It's what enables you to have an architecture with components and plugins and be able to integrate them very easily and apply any kind of changes. This is a must for enterprise development, because if you have clients, and clients want customisations, you want to be able to do that very easily without changing the core code. So that was our first challenge. There was some time invested in this tool, which in my opinion, due to the fact that we made it in pure Python code, is much more powerful than the Spring version in Java. Then came the job of actually delivering REST services.
REST is all about delivering data, rather than presentation. The next challenge was to pick a tool in order to have this data delivered. There were some tools out there for rendering on the Web, but their focus was mostly HTML and XML. That wasn't so bad, but we needed something much more flexible; we want JSON, for example. We could use ZeroMQ, for faster communication between applications. We haven't implemented in that direction just yet, but we still have the opportunity to do that.
In order to have this functionality we looked over the frameworks, but what we wanted was not even available in Java. There were only some examples of how things might be done. And so we decided to write a framework from scratch in Python. Now we have these two major components of Ally-Py. One is the dependency injection container, which allows for the plugin ability, and the second is the container which actually renders the REST services.
- This is an excerpt of a full interview article first published on the Free Software Magazine website here.