feat: expose ProfitSharePasses

[josephineweidner]

This is part of this task. The TLDR is that we want to update https://profit.sanctuary.computer/ to pull from real data in stacks. This PR scaffolds an endpoint to surface that data.

You can pull down this branch and hit this at http://localhost:3000/api/profit_share_passes:

Response

[
  {
    "id": 2,
    "desired_buffer_months": 1,
    "efficiency_cap": 1.6,
    "fica_tax_rate": 0.0765,
    "gross_expenses": 241859.05,
    "gross_payroll": 1974151.47,
    "gross_revenue": 2776966.19,
    "internals_budget_multiplier": 0.3,
    "projected_monthly_cost_of_doing_business": 221934.96,
    "total_psu_issued": 430,
    "year": 2020
  },
  {
    "id": 3,
    "desired_buffer_months": 1,
    "efficiency_cap": 1.75,
    "fica_tax_rate": 0.0765,
    "gross_expenses": 324060.21,
    "gross_payroll": 1010991.09,
    "gross_revenue": 1776824.28,
    "internals_budget_multiplier": 0.5,
    "projected_monthly_cost_of_doing_business": 111701.16,
    "total_psu_issued": 249,
    "year": 2019
  },
  {
    "id": 4,
    "desired_buffer_months": 1,
    "efficiency_cap": 1.6,
    "fica_tax_rate": 0,
    "gross_expenses": 304610,
    "gross_payroll": 653351,
    "gross_revenue": 1168836,
    "internals_budget_multiplier": 0.5,
    "projected_monthly_cost_of_doing_business": 84000,
    "total_psu_issued": 128,
    "year": 2018
  },
  {
    "id": 5,
    "desired_buffer_months": 1,
    "efficiency_cap": 1.9,
    "fica_tax_rate": 0,
    "gross_expenses": 132485.05,
    "gross_payroll": 346502.51,
    "gross_revenue": 614008.84,
    "internals_budget_multiplier": 0.5,
    "projected_monthly_cost_of_doing_business": 28750,
    "total_psu_issued": 54,
    "year": 2017
  },
  {
    "id": 1,
    "desired_buffer_months": 1,
    "efficiency_cap": 1.6,
    "fica_tax_rate": 0.0765,
    "gross_expenses": 324414.78,
    "gross_payroll": 1872023.81,
    "gross_revenue": 4027231.33,
    "internals_budget_multiplier": 0.3,
    "projected_monthly_cost_of_doing_business": 318923.51,
    "total_psu_issued": 597,
    "year": 2021
  },
  {
    "id": 6,
    "desired_buffer_months": 1.75,
    "efficiency_cap": 1.69,
    "fica_tax_rate": 0.0765,
    "gross_expenses": 428162.45,
    "gross_payroll": 2338143.13,
    "gross_revenue": 6072778.68,
    "internals_budget_multiplier": 0.7,
    "projected_monthly_cost_of_doing_business": 351184.05,
    "total_psu_issued": 718,
    "year": 2022
  },
  {
    "id": 7,
    "desired_buffer_months": 1.5,
    "efficiency_cap": 1.8,
    "fica_tax_rate": 0.0765,
    "gross_expenses": 762310.51,
    "gross_payroll": 2416423.16,
    "gross_revenue": 6189796.82,
    "internals_budget_multiplier": 1.35,
    "projected_monthly_cost_of_doing_business": 364717.69,
    "total_psu_issued": 931,
    "year": 2023
  }
]

[joshmcclain]

Great work @josephineweidner ! Some minor idiomatic comments but LGTM overall!

[josephineweidner]

FYI I'm probs gonna change this to use JSONAPI::Serializer now that I know a little more about ember so that's why I haven't merged it in (in addition to the dependency stuff which I'll resolve after #33 is merged) @joshmcclain

[hhff]

FYI I'm probs gonna change this to use JSONAPI::Serializer now that I know a little more about embe

@josephineweidner -- a widely misunderstood thing about ember is that you need to use their serializer / deserializer / ember-data store to get API data into the frontend.

You can simply make a fetch request from the route.js file instead:
https://github.com/ember-cli/ember-fetch

I'd highly recommend this approach over adding the clunky / heavy duty machinery that is JSONAPI::Serializer to rails, etc etc

[hhff]

A few notes here:

• There's inconsistency in the naming convention of these methods, some end with _from_snapshot and some don't
• we shouldn't fallback to nil, rather a type that corresponds to the type returned in a good case (so the FE doesn't need to do nil checks (this is more of a sanctuary best practice than ruby dogma)
• a good way to dig through hashes with string keys in Ruby is using dig, for example: snapshot.dig("inputs", "fica_tax_rate") || 0
• a good way to wrap a chained method in a nil check is to use try, for example: snapshot.try(:dig, ["inputs", "fica_tax_rate"]) || 0
• that said, Ruby's safe access operator probably beats try because wrapping a chained method feels unergonomic, for example: snapshot&.dig("inputs", "fica_tax_rate") || 0
• finally, logic used soley for rendering a model should be entirely in the serializer file (think of the serializer as a view, just like a HTML/XML file), not the model file (your serializer methods can do the above digging directly, rather than calling a model method)!

[josephineweidner]

Sorry @hhff - this code wasn't ready for re-review, I was in "just make it work" mode after hooking it up to the ember side. Your notes are v helpful nonetheless and I'll be sure to address them!

Marking this PR as draft until it's actually ready for your eyes again. Thanks!

[josephineweidner]

Re fallback vals: to_f takes care of this for us (which we need to do anyway bc some snapshots start storing values as strings instead of floats). Not as explicit as || 0 but it works and I think .to_f and a fallback would be misleading about to_f behavior. I can add a comment if this isn't obvious to Ruby devs?

irb(main):001:0>  nil.to_f
=> 0.0

[hhff]

Let's make this origins '*', I'd like this data to be publicly accessible to all websites

[josephineweidner]

Done, but limited it so that only profit_share_passes can be accessed. Sound good?

[hhff]

nitpicks~!

[joshmcclain]

A few minor comments but LGTM overall!