Building Web 2.0 Ready Applications with XML-RPC
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.
May 29th, 2008 at 2:47 pm
Nice post. I would love to hear more about the design process you went through for your XML-RPC app. Was it different then a normal development? I have been looking more and more into working with an rpc model.
May 29th, 2008 at 10:15 pm
Interesting! I too am interested in the design and development process. What troubles did you encounter, and overall, is it worth it?
May 30th, 2008 at 5:29 am
Elliot,
A lot of services are taking this approach, albeit a bit to late. Usually they launch their site using the typical front-end to back-end approach we all know and love.
Then, users start screaming for an API - one is developed and thrown on top, but it’s poor at best. Of course, people let the service know their API sucks and the service comes back and says, “Oh yeah? Well, we’re redeveloping our entire site to use the API - so it’s gonna get better.”
My only concern is overhead - of course, if you have the infrastructure to field API requests from who knows where I assume you have the infrastructure internally to support this as well.
The “optimization” within me wants to say pull the API out of internal applications. Why send a request to the API, have the API call the database and format the return data, then have the front-end parse and make sense of the return date when you can cut out the API and have the front-end make a request to the database and then parse and makes sense of return data. In this particular model, other developers use the API through necessity (because you’re not going to start handing out database access).
On the other hand… the information is free, separation of code, and general Web 2.0 geek-boy within me is chanting “API, API, API” in the back head of my head constantly.
Definitely a consideration as I begin to work on some of my upcoming projects - I can definitely see the benefit of making the API (which is pretty much a requirement these days) part of the site’s core, rather than a feature tacked onto the side.
May 30th, 2008 at 5:37 am
[...] is not a CodeIgniter project, although the practices outlined in the post apply just the same). In a recent post, Elliot discusses many of the benefits in developing your application’s API as part of the [...]
May 30th, 2008 at 9:59 am
As still a young Padawan in the world of Web 2.0, I’m still trying to get a basic grip on all these concepts… but I’ll be sure to consider what you’ve written when I rewrite my site. It’s dying to be rewritten.
Your mention of Java scares me. I really hope I can cling on to LAMP as much as I can
This made me understand the gist of what you’re telling in your post. What do you mean though?
May 30th, 2008 at 10:10 am
I also did a few XML-RPC Applications back in the days of CI 1.4 or was it 1.5 - it escaped me.
I think the main problem of all of these are that there is a lot of overhead and that makes them unusable for data intensive applications.
The second (not a real) problem I had was the debugging management. I wrote for every xml-rpc function a counterpart debug method and that was a lot of work (especially for a lazy guy like me ;).
Also the CI XML-RPC Service had a few little bug and was not completely implemented - maybe that change with the last version (hadn’t a look).
What I also like a lot was the high abstraction level and we shared the function methods over a lot different Applications.
May 30th, 2008 at 10:52 pm
I agree, creating a core API and building services/features on top of it can be an awesome way to go.
I’d suggested something similar to this, on a wider scale:
http://joseph.randomnetworks.com/archives/2005/07/13/api-only-services/
June 1st, 2008 at 7:50 pm
All in all, and as usual, architecture depends on the size of your application. For a Java-based monster code huge webapp like Elliot described, using XML-RPC is totally understandable. However, when it comes to building a lightweight webapp with fairly limited CRUD and audience, maybe this is not necessary.
August 4th, 2008 at 8:03 pm
I think even for small applications, XML-RPC can have it’s place.
Imagine building a CMS for a client, then being able to offer them a native desktop admin tool…
That has a great deal of value.