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.Is this a good idea? Are there any pitfalls that I'm not thinking of?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.
Is a data service API a good idea?
web services;ruby on rails;api design