I have been considering how to evolve this project for a while now. I find that some of the conventions could be made better and a lot of the classes have too many responsibilities.
One specific thing I've considered have been to split the project into two: query helpers and JSON API response helpers.
The thought behind this, is that I would like to easily facilitate the gathering of request parameters (e.g. include, count/page, limit, etc.) and the requested entity class to query the correct data. Also probably, the parsing of request body. In addition something like context/scope could be applied to facilitate multi-tenant database schemes. But this in itself is a big project, and something which is partially implemented and mixed into this current project.
The other part would be the JSON API response formatting, which would accept some query result and ensure to properly format the JSON response to respect the JSON API standard.
In this case, the bigger project would probably be the first. But splitting it out might make sense. At very least I think we should have a look at the project and see if we could do something to better separate the responsibilities.
I have been considering how to evolve this project for a while now. I find that some of the conventions could be made better and a lot of the classes have too many responsibilities.
One specific thing I've considered have been to split the project into two: query helpers and JSON API response helpers.
The thought behind this, is that I would like to easily facilitate the gathering of request parameters (e.g.
include,count/page,limit, etc.) and the requested entity class to query the correct data. Also probably, the parsing of request body. In addition something likecontext/scopecould be applied to facilitate multi-tenant database schemes. But this in itself is a big project, and something which is partially implemented and mixed into this current project.The other part would be the JSON API response formatting, which would accept some query result and ensure to properly format the JSON response to respect the JSON API standard.
In this case, the bigger project would probably be the first. But splitting it out might make sense. At very least I think we should have a look at the project and see if we could do something to better separate the responsibilities.
Any thoughts from other users of this lib?