The first problem looks a lot to me like the following => Your DB = Your API.
That's the very big problem with rails. Everything in rails lead you to think that data in DB, data in API responses (through render json: @model) and data in API requests (through: Model.new(params[:model])) is the same.
Well it's not.
That's why, even if many voices in rails community are against
1) Template views (like json.jbuilder) with aliasing every property manually should always be favored over render json: @model or other magical things (if you have rest API, or you can use graphql, it's even better)
2) Requests should be handled by form objects then form objects would translate requests data into model data, acting as a proxy, leaving the API intact if you rename some columns (or you can use graphql)
My point is: you shouldn't have to monitor db/structure.sql because changing the SQL structure should not have any impact on API contract.
The first problem looks a lot to me like the following => Your DB = Your API.
That's the very big problem with rails. Everything in rails lead you to think that data in DB, data in API responses (through render json: @model) and data in API requests (through: Model.new(params[:model])) is the same.
Well it's not.
That's why, even if many voices in rails community are against
1) Template views (like json.jbuilder) with aliasing every property manually should always be favored over render json: @model or other magical things (if you have rest API, or you can use graphql, it's even better)
2) Requests should be handled by form objects then form objects would translate requests data into model data, acting as a proxy, leaving the API intact if you rename some columns (or you can use graphql)
My point is: you shouldn't have to monitor db/structure.sql because changing the SQL structure should not have any impact on API contract.
Ok! I disagree and still like Rails. Interesting take, though.