Is a data service API a good idea?

Question

We currently have a monolithic Rails application that is really three separate applications that make use of the same data. In trying to figure out how to properly compartmentalize and break the mono-app into smaller pieces, it seems apparent that we need to have a central data service that the various pieces can communicate with, because I don't want to have to redefine a model layer for each application and/or copy models between the various applications (DRY). The idea is that since the database/persistance (including concepts like validations) are going to be the same for each component, it would make sense to have a service that can be used to query for data and create/update/delete it.

What I'm picturing is essentially a JSON API that sits between the database and my application layer. The API will not immediately be exposed to the "outside world" (although that may be something that occurs in the future); for now, it would just be communicated with internally (ie. to/from a public-facing Rails (or other) app). This API would essentially just abstract persistence logic.

1. Is this a good idea? Are there any pitfalls that I'm not thinking of?
2. If this is a good idea, does anyone know of a Rails ORM or a gem that can be used to coordinate this sort of endeavour? My vision is that once a data service is running, the actual Rails application wouldn't be using ActiveRecord anymore, but rather something which would handle querying the data API.

Answer 1

Yes, this is an excellent idea. Using a central set of web services allows you to avoid duplication and feature inconsistencies; it makes the web services the system of record for all your user-facing applications, and they can be covered by a set of homogenous automated tests, rather than trying to cobble together a suite of many types of tests. I'm not sure what the best approach to creating these web services is, in Ruby; Sinatra can definitely do it. I've personally worked with Pyramid and Django, in the Python ecosystem, and was much happier with Pyramid. Java, of course, has many frameworks for RESTful services; Jersey is the reference implementation of the relevant standard.

For Rails, I'm not sure that there's a good library for adapting ORM objects to RESTful services, unfortunately; it's likely that you will be building custom queries into your web services, to some degree, and that complicates the necessary automation to make the "magic" of an ORM work. That said, you might be surprised by how much your queries are simplified when you can literally ask for a specific business object representation; many joins and related concepts are irrelevant, and you can likely get by with a simple class that follows links within the body of the response to retrieve other resources that have been exposed to you via hypertext (HATEOAS).

Answer 2

To answer your questions:

1) Yes, it's a great idea for the good reasons cited by @syrion. You are really talking about taking a (buzzword warning) service-oriented approach. If you view it that way then you might want to broaden the scope of your services beyond CRUD operations and include business logic that you may use across your applications (it's hard to give a specific example without knowing more about your app). A very good treatment of this topic, including Rack and Sinatra options, is Service-Oriented Design with Ruby and Rails by Paul Dix.

2) There are a few ways to handle this from the perspective of the Rails apps that consume the services. In a similar situation I wrote my own gem as an SDK to my services. Internally I used HTTParty for communicating with the services. You might also want to check out ActiveModel as a replacement for ActiveRecord in this situation.