#Report Calc API
##API Abstraction
###Http API
There would be thin html presenter layer that would call the api and hand that off to the view. The api would have a JSON presenter layer.
Pros
- Gives a strait forward way to separation full report generation from periodically saving values.
- Separate Report generation from Business logic, which gives Altoros a layer of separation to create views.
- Could feed report values into future software, like Logi.
Cons
- Additional level of complexity
- More points of failure
- Things that are already in the database would need to be duplicated into the api and possible causing the api perceistance to be duplicated, but mabye that would be a feature as a way to store historical data for the whole plan.
json-schema
- Can create valid data models from the schema wihout loaded up the whole app
- https://github.com/ruby-json-schema/json-schema
###Ruby API
This layer could sit before or after the presenter.
Pros
- Less Complex
- Abiltiy to only save needed values
Cons
- Easy to Cross concerns
##API Store
###Postgres JSON
Pros
- Provides schema flexibility
Cons
- Not as easy to query as Relational data
##Summary
No matter what choice I think it is very important that there be a separation of concerns. It would get very messy if all we did was add bunch of code into the current presenters that would handle persistence. We need additional information before we can make the best choice.