Think of all the things you can do at Wikia: edit articles, live chat with other users, collect badges, organize content, or just spend hours and hours reading away on your favorite topics. Scale that over our 360,000 communities, each with its own unique design and content, and you can see just how much variety we have here.
Our communities are built on that. What goes unseen by communities, though, is how a lot of variety can lead to big coding challenges for our engineers and product managers. Given all Wikia can do, we've built up a pretty big codebase over the years.
A few years ago, some of our most experienced engineers got together and asked if there was a way to chop up the codebase. They wanted to see if there was an easier way to maintain all of the coding and features that help Wikia thrive. After all, that would allow for faster and more efficient software development. I'm happy to tell you that we’re making great progress in doing so!
The solution is what's known as Service-Oriented Architecture (SOA) and, as both a long-time wiki editor (I just celebrated my 10 year wiki-editing anniversary!) and computer programmer, I'm excited to explain our approach and share what's happening behind the scenes in Wikia’s software development.
Terms to Know
To better explain the technical changes Wikia has been working on, let's define some important concepts first.
MediaWiki: MediaWiki is the primary engine that has been the backbone of Wikia since we launched in 2006. MediaWiki is integral to the creation of the “wiki” concept and is best identifiable by ease of editing, presentation of user-created content, a simple user group structure, and the ability to track edit histories.
A service, in technological terms, is a small piece of software responsible for doing a single, common task. It can be coded in any language. Service-Oriented Architecture, therefore, is when you design a system that allows all of a website's tasks to be handled by individual services that work together, rather than one giant piece of software that does everything.
So What’s the Problem?
In trying to understand the advantages of using an SOA model versus the MediaWiki model, let’s pretend the monolith of MediaWiki is a city. All of its citizens are responsible for handling all the business of the city, from construction to policing to shopkeeping. All of the day-to-day business is handled okay by the city, but if a fire breaks out, it’d be kind of weird to think a shopkeeper, police officer, or construction worker will be responsible for fighting the fire instead of firemen who are specifically dedicated to firefighting.
Continuing our analogy, let’s look at what kind of a city a Service-Oriented model would offer. In that city, you would have citizens specifically in charge of construction, policing, and shopkeeping. That would be the only thing those people focus on. If a fire breaks out, firefighters come to the scene. I don’t know about you, but if my house catches on fire, I feel a lot better if a firefighter is the first on the scene instead of a baker. Though the idea of the fire being smothered in frosting might be good for a few laughs.
This generalization is a good description of why Wikia now favors the SOA method. Specific advantages of SOA versus core MediaWiki are:
- Less complexity. It's much easier for a software engineer to understand, fix, and improve a piece of software if its scope is small and its code is contained in one place
- Efficiency. SOA enables us to use software languages like Java or Python, which tend to have better performance for doing certain tasks that PHP does not do well
- Adaptability. MediaWiki is huge and slow to update. On the flipside, the internet changes fast. MediaWiki is often far behind in necessary features, like Mobile App development.
You might be surprised to know that Wikia’s switch to an SOA model has been occurring in bits and pieces over the last year. Having an SOA-model does not mean you get a flashy, glitzy new Wikia. SOA just takes pieces of what MediaWiki does for Wikia, rebuilds the code to be efficient and effective, and then plugs the code back in. You really shouldn’t notice the difference, though rewriting the code does often allow us to add an extra piece of functionality or two.
One great example of that is our account login system. Believe it or not, yes, that’s changed quite a bit in the last year! MediaWiki’s user authentication system had some inefficiencies in handling a user database Wikia’s size and easily accepting addons like Facebook Connect. So last year, we began designing something called Helios, which allows for a much more secure and swift registration and login process. Helios runs independent of MediaWiki and “talks” to MediaWiki through a simple API.
In addition, we’ve created services that specifically handle user group permissions and user preferences. Most of that development has happened in the Mobile App and Mobile Web world. In fact, we’ve been able to use Helios to authenticate users logging into Wikia on Mobile Web and Mobile Apps, a far easier task than it would have been to try to plug the existing MediaWiki authentication system into these mobile tools.
This is just the beginning of our efforts to make Wikia a more efficient system. This will allow us to better design features and code to continue growing Wikia far into the future. If you have any questions about the development of Service-Oriented Architecture on Wikia, we're happy to answer them in the comments!
Want to receive updates on the latest Staff blog posts? Then click here to follow this blog.