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.
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:
-
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.
-
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.
-
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.
1