My company has this Huge Database that gets fed with (many) events from multiple sources, for monitoring and reporting purposes. So far, every new dashboard or graphic from the data is a new Rails app with extra tables in the Huge Database and full access to the database contents.
Lately, there has been an idea floating around of having external (as in, not our company but sister companies) clients to our data, and it has been decided we should expose a read-only RESTful API to consult our data.
My point is – should we use an API for our own projects too? Is it overkill to access a RESTful API, even for “local” projects, instead of direct access to the database? I think it would pay off in terms of unifying our team’s access to the data – but is it worth the extra round-trip? And can a RESTful API keep up with the demands of running 20 or so queries per second and exposing the results via JSON?
Thanks for any input!
I think there’s a lot to be said for consistency. If you’re providing an API for your clients, it seems to me that by using the same API you’ll understand it better wrt. supporting it for your clients, you’ll be testing it regularly (beyond your regression tests), and you’re sending a message that it’s good enough for you to use, so it should be fine for your clients.
By hiding everything behind the API, you’re at liberty to change the database representations and not have to change both API interface code (to present the data via the API) and the database access code in your in-house applications. You’d only change the former.
Finally, such performance questions can really only be addressed by trying it and measuring. Perhaps it’s worth knocking together a prototype API system and studying it under load ?