For the last month at work I’ve been building an admin backend for a huge application. The application runs as a large Java XML-RPC server which takes request, performs database and cache operations and returns data.
At first I hated this idea, mainly because it was so different to the typical lamp development flow I was used to. However, now I’m completely converted, and I feel as though it’s my duty to share with you my experience, and preach to you the way of the divided application.
Lets start back at the beginning. Typically most Lamp developers build one application which performs basic crud operations on data. This is the core of almost all web apps. This application will usually be split into 2 sections: A frontend, and a backend or admin section. So its immediately obvious that already, we are essentially writing 2 different applications.
So, let’s say that we agree that the typical web application is actually 2 applications. Then it would make sense for them to share a common data model. Afterall, there’s no point in rewriting SQL.
This is where an XML-RPC based API comes into play. By building a central application which simply acts as the model in this alternative MVC structure, you allow different applications to connect to it and use the same functionality.
Until now, our shiny new XML-RPC API based applications just do the same thing as the original single application approach, so what makes this new API approach so special?
Well, the name says it all really. API API API. They’re integral to any new trendy and succesful web application. So why build it as an afterthought and tack it onto your main application? This xmlrpc based approach means you’re building and using the API you will later give 3rd parties (with proper authentication) access to.
Separation of functionality has always been at the heart of good programming practices. And this centralized API approach takes this one step further. Just say you have a PHP developer who’s building the front-end for your CMS… but he/she is not too hot on MySQL queries. Don’t worry about it! – They just call Blog.getPosts(10), and your MySQL guru writes a beautiful query inside the XML-RPC API that gets and returns the posts.
The developers of the ‘addon’ applications never have to worry about database operations. They just call the remote API and watch it all work.
This also helps your application to scale too. By load balancing several apache servers all running your XML-RPC API, you can make the service instantly more robust and reliable.
Database portability is next on the list too… your API is the only code which actually runs queries on your database. So if you decide to push your database to Oracle… no worries! – Just change your API.
Web, desktop, phone… ?
Because your central XML-RPC service handles data using a standard protocol, you can connect to it in almost any language, on almost any platform.
Want a cocoa written mac admin program for your CMS? No problem! Or how about a java based cross platform version of your ecommerce site. Simple!
The whole point in building an XML-RPC API based application is to give you flexibility, code separation, and permission based functionality.
I’d strongly recommend this approach when you come to write your next web application.
