Does ORM at any point become a "requirement" for RESTful API?

Question

I've started building a RESTful API in PHP's Slim framework. The framework appealed to me because of its light-weight design and routing features. I am using PostgreSQL for the database.

However, the dataset is somewhat large - there would be about 20 types of resources, with many associations and nested sets. So far, I have implemented my own custom ORM methods on resource classes, such as "select from database by primary key". Slim does not provide any ORM features. I am wondering if the scale of the API is large enough to recommend the use of a framework with built-in ORM support or integration with an ORM such as Doctrine or Propel.

Am I at the point where I should use an ORM to help mitigate the complexity of changes to database tables, attribute names, etc?

I am also open to using other technologies - it seems Python's Django is highly regarded as a framework for building RESTful APIs.

Answer 1

An ORM is not a requirement for any project of any scale. More often, small projects start with an ORM, then abandon it when scaling up.

If database changes become too complex:

1. Ask yourself why is the database changing too often.

   I had to work on projects where database was changed at least once per day, just because the project was badly thought, requirements not gathered correctly, and database originally created by a person who knew nothing about databases in general. An unnecessary nightmare.

2. If you've found that changes are due to the complex, volatile structure of the data which is constantly extending, consider using non-relational databases. A document model (such as what is used in MongoDB) may better correspond to your needs.

3. If there are no that much changes, but you're simply overwhelmed by the size of the schema, consider splitting your service into multiple ones, each owning a part of a database.

   By constraining each service to use only a part of a database (and call other services to access other data), you may make it really simple to deal with changes: the scope of each change would be limited to a concerned service instead of being spread over the code base.