[{"_1":2,"_1594":-5,"_1595":-5},"loaderData",{"_3":4,"_22":23},"root",{"_5":6},"current",{"_7":8,"_9":10,"_21":8},"development",false,"env",{"_11":12,"_13":14,"_15":16,"_17":18,"_19":20},"COMMIT_SHA","e212709e3b739295987e44976eb456927a790bd9","IMAGE_CDN","https://planetscale-images.imgix.net","IMAGE_CDN_ENABLED","true","INTERNAL_API","https://api.planetscale.com","SENTRY_DSN","https://bd81903b44804e22a06bdc0c1a91b303@o499952.ingest.us.sentry.io/4504531942572032","userSignedIn","routes/blog.author.$slug",{"_24":25,"_30":31,"_1584":1585,"_3":1593},"author",{"_26":27,"_28":29},"slug","jasoncharnes","name","Jason Charnes","blogs",[32],{"_26":33,"_34":35,"_1520":1521,"_1522":-7,"_1523":1524,"_1531":1565,"_1566":1567,"_1570":1571,"_1573":1574,"_1575":1576,"_1577":1578},"rails-safety-mechanisms","body",[36,46,51,66,85,90,99,104,109,114,119,130,135,154,165,182,187,192,197,206,211,216,228,233,238,249,271,282,292,297,302,307,324,329,346,357,368,380,385,390,395,400,405,410,416,431,436,441,458,463,480,491,496,501,512,517,522,527,538,555,560,565,576,581,591,596,607,618,623,628,640,650,655,667,677,686,697,708,712,723,728,739,744,749,760,776,781,792,797,808,825,842,854,865,881,892,903,908,925,930,935,946,962,967,995,1006,1011,1016,1021,1038,1043,1054,1065,1070,1081,1086,1091,1101,1106,1111,1122,1142,1153,1158,1169,1174,1179,1190,1201,1206,1212,1217,1241,1246,1251,1256,1267,1272,1277,1292,1303,1313,1318,1329,1334,1339,1357,1368,1377,1382,1387,1398,1403,1412,1417,1428,1433,1444,1449,1454,1459,1470,1479,1484,1489,1500,1505,1510,1515],["SingleFetchClassInstance",37],{"_38":39,"_28":40,"_41":42,"_43":44},"$$mdtype","Tag","p","attributes",{},"children",[45],"Companies build products with Ruby on Rails because of its focus on efficiency. The framework comes with a set of defaults that allows you to focus on building, not configuring.",["SingleFetchClassInstance",47],{"_38":39,"_28":40,"_41":48,"_43":49},{},[50],"Defaults can have limits. We can often find ourselves with paper cuts if we’re not careful. Fear not! Rails has conventions for this, too. Let’s look at some tools the framework gives us to protect ourselves.",["SingleFetchClassInstance",52],{"_38":39,"_28":53,"_41":54,"_43":57},"h2",{"_55":56},"id","mass-assignment-protection-in-rails",[58],["SingleFetchClassInstance",59],{"_38":39,"_28":60,"_41":61,"_43":64},"a",{"_62":63},"href","#mass-assignment-protection-in-rails",[65],"Mass assignment protection in Rails",["SingleFetchClassInstance",67],{"_38":39,"_28":40,"_41":68,"_43":69},{},[70,71,77,78,84],"One of the first things Rails developers learn is handling form parameters. The ",["SingleFetchClassInstance",72],{"_38":39,"_28":73,"_41":74,"_43":75},"code",{},[76],"params"," object contains all the form parameters for us to use in controllers and views. But whenever Rails generates a scaffold it uses something called ",["SingleFetchClassInstance",79],{"_38":39,"_28":80,"_41":81,"_43":82},"strong",{},[83],"strong parameters",".",["SingleFetchClassInstance",86],{"_38":39,"_28":40,"_41":87,"_43":88},{},[89],"What are strong parameters, exactly? When creating or updating an Active Record model we can pass an optional hash of attributes.",["SingleFetchClassInstance",91],{"_38":39,"_28":92,"_41":93,"_43":98},"CodeBlock",{"_94":95,"_96":97},"html","

User.create(name: \"Jason Charnes\", location: \"Memphis\")`\n

","language","ruby",[],["SingleFetchClassInstance",100],{"_38":39,"_28":40,"_41":101,"_43":102},{},[103],"This pairs beautifully with the Rails form helpers:",["SingleFetchClassInstance",105],{"_38":39,"_28":92,"_41":106,"_43":108},{"_94":107,"_96":-7},"

<%= form_with model: @user do |form| %>\n  <%= form.text_field :name %>\n  <%= form.text_field :location %>\n  <%= form.submit %>\n<% end %>\n

",[],["SingleFetchClassInstance",110],{"_38":39,"_28":40,"_41":111,"_43":112},{},[113],"The parameters sent from the form to the controller look like this:",["SingleFetchClassInstance",115],{"_38":39,"_28":92,"_41":116,"_43":118},{"_94":117,"_96":97},"

{user: {name: \"Jason Charnes\", location: \"Memphis\"}}\n

",[],["SingleFetchClassInstance",120],{"_38":39,"_28":40,"_41":121,"_43":122},{},[123,124,129],"We can pass the ",["SingleFetchClassInstance",125],{"_38":39,"_28":73,"_41":126,"_43":127},{},[128],"user"," hash directly:",["SingleFetchClassInstance",131],{"_38":39,"_28":92,"_41":132,"_43":134},{"_94":133,"_96":97},"

class UsersController < ApplicationController\n  def create\n    User.create!(params[:user])\n  end\nend\n

",[],["SingleFetchClassInstance",136],{"_38":39,"_28":40,"_41":137,"_43":138},{},[139],["SingleFetchClassInstance",140],{"_38":39,"_28":141,"_41":142,"_43":145},"Callout",{"_143":144},"type","warning",[146,147,153],"🚨 This is ",["SingleFetchClassInstance",148],{"_38":39,"_28":149,"_41":150,"_43":151},"em",{},[152],"mass assignment","; it’s dangerous.",["SingleFetchClassInstance",155],{"_38":39,"_28":40,"_41":156,"_43":157},{},[158,159,164],"While creating the record, we’re mass assigning the attributes. This is simple, clean, and ",["SingleFetchClassInstance",160],{"_38":39,"_28":149,"_41":161,"_43":162},{},[163],"appears"," to work great, but there’s a problem.",["SingleFetchClassInstance",166],{"_38":39,"_28":40,"_41":167,"_43":168},{},[169,170,175,176,181],"The ",["SingleFetchClassInstance",171],{"_38":39,"_28":73,"_41":172,"_43":173},{},[174],"User"," model also has an ",["SingleFetchClassInstance",177],{"_38":39,"_28":73,"_41":178,"_43":179},{},[180],"admin"," boolean that defaults to false. What if our end-user is sneaky and adds this to the form?",["SingleFetchClassInstance",183],{"_38":39,"_28":92,"_41":184,"_43":186},{"_94":185,"_96":94},"

<input type=\"hidden\" name=\"user[admin]\" value=\"true\" />\n

",[],["SingleFetchClassInstance",188],{"_38":39,"_28":40,"_41":189,"_43":190},{},[191],"Now the params look like this:",["SingleFetchClassInstance",193],{"_38":39,"_28":92,"_41":194,"_43":196},{"_94":195,"_96":97},"

{user: {name: \"Jason Charnes\", location: \"Memphis\", admin: \"true\"}}\n

",[],["SingleFetchClassInstance",198],{"_38":39,"_28":40,"_41":199,"_43":200},{},[201,202,84],"We’re passing the entire list of parameters to Active Record, including ",["SingleFetchClassInstance",203],{"_38":39,"_28":73,"_41":204,"_43":205},{},[180],["SingleFetchClassInstance",207],{"_38":39,"_28":92,"_41":208,"_43":210},{"_94":209,"_96":97},"

class UsersController < ApplicationController\n  def create\n    @user = User.create!(params[:user])\n    @user.admin? #=> true\n  end\nend\n

",[],["SingleFetchClassInstance",212],{"_38":39,"_28":40,"_41":213,"_43":214},{},[215],"Yikes, we gave away the keys to the kingdom. This is the role strong parameters play.",["SingleFetchClassInstance",217],{"_38":39,"_28":218,"_41":219,"_43":221},"h3",{"_55":220},"strong-parameters",[222],["SingleFetchClassInstance",223],{"_38":39,"_28":60,"_41":224,"_43":226},{"_62":225},"#strong-parameters",[227],"Strong parameters",["SingleFetchClassInstance",229],{"_38":39,"_28":40,"_41":230,"_43":231},{},[232],"Instead of mass assignment (passing the raw params directly to Active Record), we use strong parameters to signal which attributes are allowed.",["SingleFetchClassInstance",234],{"_38":39,"_28":92,"_41":235,"_43":237},{"_94":236,"_96":97},"

class UsersController < ApplicationController\n  def create\n    User.create!(user_params)\n  end\n\n  private\n\n  def user_params\n    params.require(:user).permit(:name)\n  end\nend\n

",[],["SingleFetchClassInstance",239],{"_38":39,"_28":40,"_41":240,"_43":241},{},[242,243,248],"Here, we define a ",["SingleFetchClassInstance",244],{"_38":39,"_28":73,"_41":245,"_43":246},{},[247],"user_params"," method that is responsible for allowing specific parameters through.",["SingleFetchClassInstance",250],{"_38":39,"_28":40,"_41":251,"_43":252},{},[253,254,258,259,264,265,270],"We start by telling the ",["SingleFetchClassInstance",255],{"_38":39,"_28":73,"_41":256,"_43":257},{},[76]," object that we ",["SingleFetchClassInstance",260],{"_38":39,"_28":149,"_41":261,"_43":262},{},[263],"require"," the parameters to have a key of ",["SingleFetchClassInstance",266],{"_38":39,"_28":73,"_41":267,"_43":268},{},[269],":user",". If the params don’t have this key, an error is raised and the request is halted.",["SingleFetchClassInstance",272],{"_38":39,"_28":40,"_41":273,"_43":274},{},[275,276,281],"From there we provide a list of permitted attributes to the ",["SingleFetchClassInstance",277],{"_38":39,"_28":73,"_41":278,"_43":279},{},[280],"permit"," method.",["SingleFetchClassInstance",283],{"_38":39,"_28":40,"_41":284,"_43":285},{},[286,287,291],"Now, if our end-user tries to pass ",["SingleFetchClassInstance",288],{"_38":39,"_28":73,"_41":289,"_43":290},{},[180]," as a parameter, Rails will exclude it from the list of params passed to Active Record.",["SingleFetchClassInstance",293],{"_38":39,"_28":40,"_41":294,"_43":295},{},[296],"Rails will log unpermitted parameters by default. This is useful for debugging in development and looking for bad actors in production. If you want to take things further, you can tell Rails to raise an error if unpermitted parameters are passed:",["SingleFetchClassInstance",298],{"_38":39,"_28":92,"_41":299,"_43":301},{"_94":300,"_96":97},"

config.action_controller.action_on_unpermitted_parameters = :raise\n

",[],["SingleFetchClassInstance",303],{"_38":39,"_28":40,"_41":304,"_43":305},{},[306],"Strong parameters are a controller-level feature. Is there a way to enforce this in the model? Rails doesn’t provide this, but it used to.",["SingleFetchClassInstance",308],{"_38":39,"_28":40,"_41":309,"_43":310},{},[311,312,317,318,323],"Before the introduction of strong parameters in Rails 4, mass assignment protection happened at the model level. (Does anyone remember ",["SingleFetchClassInstance",313],{"_38":39,"_28":73,"_41":314,"_43":315},{},[316],"attr_protected"," and ",["SingleFetchClassInstance",319],{"_38":39,"_28":73,"_41":320,"_43":321},{},[322],"attr_accessible","?!)",["SingleFetchClassInstance",325],{"_38":39,"_28":40,"_41":326,"_43":327},{},[328],"The strong parameters pattern is more flexible. You likely want to permit different attributes depending on the context. A user shouldn’t set their admin status. But an existing admin may be able to set it.",["SingleFetchClassInstance",330],{"_38":39,"_28":40,"_41":331,"_43":332},{},[333,334,339,340,345],"While it’s ",["SingleFetchClassInstance",335],{"_38":39,"_28":149,"_41":336,"_43":337},{},[338],"easier"," to define it in the model, it’s ",["SingleFetchClassInstance",341],{"_38":39,"_28":149,"_41":342,"_43":343},{},[344],"simpler"," to let the controller do it.",["SingleFetchClassInstance",347],{"_38":39,"_28":53,"_41":348,"_43":350},{"_55":349},"n1-prevention-in-rails",[351],["SingleFetchClassInstance",352],{"_38":39,"_28":60,"_41":353,"_43":355},{"_62":354},"#n1-prevention-in-rails",[356],"N+1 prevention in Rails",["SingleFetchClassInstance",358],{"_38":39,"_28":40,"_41":359,"_43":360},{},[361,367],["SingleFetchClassInstance",362],{"_38":39,"_28":60,"_41":363,"_43":365},{"_62":364},"/blog/what-is-n-1-query-problem-and-how-to-solve-it",[366],"N+1 queries"," are unfortunately easy to perform in Active Record. ✨",["SingleFetchClassInstance",369],{"_38":39,"_28":40,"_41":370,"_43":371},{},[372,373,379],"If we access an association we haven’t loaded, Rails will make the database lookup on our behalf. Rails has our back here. It comes at a cost, though. (Unless you ",["SingleFetchClassInstance",374],{"_38":39,"_28":60,"_41":375,"_43":377},{"_62":376},"https://www.youtube.com/watch?v=ktZLpjCanvg&t=241s",[378],"view N+1s as a feature",".)",["SingleFetchClassInstance",381],{"_38":39,"_28":40,"_41":382,"_43":383},{},[384],"Pretend we’re rendering a list of orders:",["SingleFetchClassInstance",386],{"_38":39,"_28":92,"_41":387,"_43":389},{"_94":388,"_96":97},"

class OrdersController < ApplicationController\n  def index\n    @orders = Order.all\n  end\nend\n

",[],["SingleFetchClassInstance",391],{"_38":39,"_28":92,"_41":392,"_43":394},{"_94":393,"_96":-7},"

<% @orders.each do |order| %>\n  <tr>\n    <td><%= order.id %></td>\n    <td><%= order.customer.name %></td>\n    <td><%= order.created_at %></td>\n  </tr>\n<% end %>\n

",[],["SingleFetchClassInstance",396],{"_38":39,"_28":40,"_41":397,"_43":398},{},[399],"We’re rendering the customer’s name on each order. An order belongs to a customer.",["SingleFetchClassInstance",401],{"_38":39,"_28":92,"_41":402,"_43":404},{"_94":403,"_96":97},"

class Order < ApplicationRecord\n  belongs_to :customer\nend\n

",[],["SingleFetchClassInstance",406],{"_38":39,"_28":40,"_41":407,"_43":408},{},[409],"We didn’t ask the database for customers, though. Just orders. The logs show the single database query for orders. ✅",["SingleFetchClassInstance",411],{"_38":39,"_28":92,"_41":412,"_43":415},{"_94":413,"_96":414},"

SELECT \"orders\".* FROM \"orders\"\n

","sql",[],["SingleFetchClassInstance",417],{"_38":39,"_28":40,"_41":418,"_43":419},{},[420,421,430],"And a customers table query for ",["SingleFetchClassInstance",422],{"_38":39,"_28":80,"_41":423,"_43":424},{},[425],["SingleFetchClassInstance",426],{"_38":39,"_28":149,"_41":427,"_43":428},{},[429],"each order"," we rendered. ❌",["SingleFetchClassInstance",432],{"_38":39,"_28":92,"_41":433,"_43":435},{"_94":434,"_96":414},"

SELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 1], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 2], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 3], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 4], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 5], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 6], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 7], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 8], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 9], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 10], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 11], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 12], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 13], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 14], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2  [[\"id\", 15], [\"LIMIT\", 1]]\n

",[],["SingleFetchClassInstance",437],{"_38":39,"_28":40,"_41":438,"_43":439},{},[440],"Rails knows customers aren’t loaded, so it lazy loads (does a database lookup for) each customer on the fly.",["SingleFetchClassInstance",442],{"_38":39,"_28":40,"_41":443,"_43":444},{},[445,446,451,452,457],"The query returns 15 orders, which means 15 individual customer queries. This is what I mean by N+1. We have ",["SingleFetchClassInstance",447],{"_38":39,"_28":73,"_41":448,"_43":449},{},[450],"N"," order records. For every order, we have ",["SingleFetchClassInstance",453],{"_38":39,"_28":73,"_41":454,"_43":455},{},[456],"+1"," more query to look up the customer.",["SingleFetchClassInstance",459],{"_38":39,"_28":40,"_41":460,"_43":461},{},[462],"This is a problem when working with large datasets.",["SingleFetchClassInstance",464],{"_38":39,"_28":40,"_41":465,"_43":466},{},[467,468,473,474,479],"Each request to the customers table isn’t necessarily a bottleneck — they’re pretty quick. But they add up. And sometimes it’s not just ",["SingleFetchClassInstance",469],{"_38":39,"_28":149,"_41":470,"_43":471},{},[472],"one"," association per record. It’s ",["SingleFetchClassInstance",475],{"_38":39,"_28":149,"_41":476,"_43":477},{},[478],"many"," associations per record.",["SingleFetchClassInstance",481],{"_38":39,"_28":218,"_41":482,"_43":484},{"_55":483},"the-solution-to-n1s",[485],["SingleFetchClassInstance",486],{"_38":39,"_28":60,"_41":487,"_43":489},{"_62":488},"#the-solution-to-n1s",[490],"The solution to N+1s",["SingleFetchClassInstance",492],{"_38":39,"_28":40,"_41":493,"_43":494},{},[495],"We fix this by preloading associations.",["SingleFetchClassInstance",497],{"_38":39,"_28":92,"_41":498,"_43":500},{"_94":499,"_96":97},"

class OrdersController < ApplicationController\n  def index\n    @orders = Order.includes(:customer).all\n  end\nend\n

",[],["SingleFetchClassInstance",502],{"_38":39,"_28":40,"_41":503,"_43":504},{},[505,506,511],"By adding the ",["SingleFetchClassInstance",507],{"_38":39,"_28":73,"_41":508,"_43":509},{},[510],".includes"," method with the association we want to preload, Rails ensures that every corresponding customer is loaded.",["SingleFetchClassInstance",513],{"_38":39,"_28":40,"_41":514,"_43":515},{},[516],"Instead of 15 extra SQL queries, we only have 1 extra query:",["SingleFetchClassInstance",518],{"_38":39,"_28":92,"_41":519,"_43":521},{"_94":520,"_96":414},"

SELECT \"orders\".* FROM \"orders\"\n\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" IN ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15)  [[\"id\", 1], [\"id\", 2], [\"id\", 3], [\"id\", 4], [\"id\", 5], [\"id\", 6], [\"id\", 7], [\"id\", 8], [\"id\", 9], [\"id\", 10], [\"id\", 11], [\"id\", 12], [\"id\", 13], [\"id\", 14], [\"id\", 15]]\n

",[],["SingleFetchClassInstance",523],{"_38":39,"_28":40,"_41":524,"_43":525},{},[526],"Over time it’s easier to know when you’re introducing an N+1 query, but it’s still easy to miss them. Let’s look at how we can catch N+1s before shipping to production.",["SingleFetchClassInstance",528],{"_38":39,"_28":218,"_41":529,"_43":531},{"_55":530},"before-rails-61",[532],["SingleFetchClassInstance",533],{"_38":39,"_28":60,"_41":534,"_43":536},{"_62":535},"#before-rails-61",[537],"Before Rails 6.1",["SingleFetchClassInstance",539],{"_38":39,"_28":40,"_41":540,"_43":541},{},[169,542,548,549,554],["SingleFetchClassInstance",543],{"_38":39,"_28":60,"_41":544,"_43":546},{"_62":545},"https://github.com/flyerhzm/bullet",[547],"Bullet gem"," is ",["SingleFetchClassInstance",550],{"_38":39,"_28":149,"_41":551,"_43":552},{},[553],"the"," tool for discovering N+1s.",["SingleFetchClassInstance",556],{"_38":39,"_28":40,"_41":557,"_43":558},{},[559],"Bullet keeps an eye out for N+1 queries in your application. From Rails logs to notifying you in Slack, it has many ways to warn you of N+1 queries.",["SingleFetchClassInstance",561],{"_38":39,"_28":40,"_41":562,"_43":563},{},[564],"Remember, it’s still up to you to listen and fix the N+1s. 😅",["SingleFetchClassInstance",566],{"_38":39,"_28":218,"_41":567,"_43":569},{"_55":568},"rails-61",[570],["SingleFetchClassInstance",571],{"_38":39,"_28":60,"_41":572,"_43":574},{"_62":573},"#rails-61",[575],"Rails 6.1+",["SingleFetchClassInstance",577],{"_38":39,"_28":40,"_41":578,"_43":579},{},[580],"If you don’t want to fool with another dependency or know that you’ll just ignore Bullet warning you of N+1s, there’s a more invasive option.",["SingleFetchClassInstance",582],{"_38":39,"_28":40,"_41":583,"_43":584},{},[585,586,84],"Rails 6.1 introduced a mechanism for detecting down N+1s: ",["SingleFetchClassInstance",587],{"_38":39,"_28":73,"_41":588,"_43":589},{},[590],"strict_loading",["SingleFetchClassInstance",592],{"_38":39,"_28":92,"_41":593,"_43":595},{"_94":594,"_96":97},"

class Order < ApplicationRecord\n  belongs_to :customer, strict_loading: true\nend\n

",[],["SingleFetchClassInstance",597],{"_38":39,"_28":40,"_41":598,"_43":599},{},[600,601,606],"Adding this option to the customer association results in an ",["SingleFetchClassInstance",602],{"_38":39,"_28":73,"_41":603,"_43":604},{},[605],"ActiveRecord::StrictLoadingViolationError"," raised if Rails detects you’re lazy loading the association.",["SingleFetchClassInstance",608],{"_38":39,"_28":40,"_41":609,"_43":610},{},[611,612,617],"When we encounter this error, it’s clear to us ",["SingleFetchClassInstance",613],{"_38":39,"_28":149,"_41":614,"_43":615},{},[616],"what"," happened:",["SingleFetchClassInstance",619],{"_38":39,"_28":92,"_41":620,"_43":622},{"_94":621,"_96":-7},"

`Order` is marked for strict_loading. The Customer association named `:customer` cannot be lazily loaded.\n

",[],["SingleFetchClassInstance",624],{"_38":39,"_28":40,"_41":625,"_43":626},{},[627],"Adding this option to each association is tedious! Luckily, there’s a way to enable this functionality globally.",["SingleFetchClassInstance",629],{"_38":39,"_28":630,"_41":631,"_43":633},"h4",{"_55":632},"applying-strict-loading-in-development",[634],["SingleFetchClassInstance",635],{"_38":39,"_28":60,"_41":636,"_43":638},{"_62":637},"#applying-strict-loading-in-development",[639],"Applying strict loading in development",["SingleFetchClassInstance",641],{"_38":39,"_28":40,"_41":642,"_43":643},{},[644,645],"If you only want an error raised in development, not production, you can enable the option in ",["SingleFetchClassInstance",646],{"_38":39,"_28":73,"_41":647,"_43":648},{},[649],"config/development.rb",["SingleFetchClassInstance",651],{"_38":39,"_28":92,"_41":652,"_43":654},{"_94":653,"_96":97},"

config.active_record.strict_loading_by_default = true\n

",[],["SingleFetchClassInstance",656],{"_38":39,"_28":40,"_41":657,"_43":658},{},[659,660,666],"I like Aaron Francis’ idea of enforcing strict loading in development only. In our companion article on ",["SingleFetchClassInstance",661],{"_38":39,"_28":60,"_41":662,"_43":664},{"_62":663},"/blog/laravels-safety-mechanisms",[665],"Laravel’s safety mechanisms",", he suggests:",["SingleFetchClassInstance",668],{"_38":39,"_28":669,"_41":670,"_43":671},"blockquote",{},[672],["SingleFetchClassInstance",673],{"_38":39,"_28":40,"_41":674,"_43":675},{},[676],"Lazy loading relationships does not affect the correctness of your application, merely the performance of it. Ideally, all the relations you need are eager loaded, but if not, it simply falls through and lazy loads the required relationships.",["SingleFetchClassInstance",678],{"_38":39,"_28":669,"_41":679,"_43":680},{},[681],["SingleFetchClassInstance",682],{"_38":39,"_28":40,"_41":683,"_43":684},{},[685],"For that reason, we recommend disallowing lazy loading in every environment except production. Hopefully, all lazy loads will be caught in local development or testing, but in the rare case that a lazy load makes its way into production, your app will continue to work just fine, if a bit slower.",["SingleFetchClassInstance",687],{"_38":39,"_28":630,"_41":688,"_43":690},{"_55":689},"applying-strict-loading-regardless-of-the-environment",[691],["SingleFetchClassInstance",692],{"_38":39,"_28":60,"_41":693,"_43":695},{"_62":694},"#applying-strict-loading-regardless-of-the-environment",[696],"Applying strict loading regardless of the environment",["SingleFetchClassInstance",698],{"_38":39,"_28":40,"_41":699,"_43":700},{},[701,702,707],"If performance is critical and it’s important to raise this error in all environments, including production, apply the option in ",["SingleFetchClassInstance",703],{"_38":39,"_28":73,"_41":704,"_43":705},{},[706],"config/application.rb",":",["SingleFetchClassInstance",709],{"_38":39,"_28":92,"_41":710,"_43":711},{"_94":653,"_96":97},[],["SingleFetchClassInstance",713],{"_38":39,"_28":53,"_41":714,"_43":716},{"_55":715},"asynchronous-association-destruction",[717],["SingleFetchClassInstance",718],{"_38":39,"_28":60,"_41":719,"_43":721},{"_62":720},"#asynchronous-association-destruction",[722],"Asynchronous association destruction",["SingleFetchClassInstance",724],{"_38":39,"_28":40,"_41":725,"_43":726},{},[727],"Active Record provides a mechanism for deleting associated records when a parent record is deleted.",["SingleFetchClassInstance",729],{"_38":39,"_28":40,"_41":730,"_43":731},{},[732,733,738],"The quickest, simplest way to delete dependent data is by providing the ",["SingleFetchClassInstance",734],{"_38":39,"_28":73,"_41":735,"_43":736},{},[737],"dependent: :delete_all"," option on the association:",["SingleFetchClassInstance",740],{"_38":39,"_28":92,"_41":741,"_43":743},{"_94":742,"_96":97},"

class Order < ApplicationRecord\n  has_many :invoices, dependent: :delete_all\nend\n

",[],["SingleFetchClassInstance",745],{"_38":39,"_28":40,"_41":746,"_43":747},{},[748],"Deleting this order will execute a separate, single SQL query to delete all the associated invoices.",["SingleFetchClassInstance",750],{"_38":39,"_28":40,"_41":751,"_43":752},{},[753,754,759],"Sometimes, though, the dependent records have “on delete” callbacks that need to run. Because ",["SingleFetchClassInstance",755],{"_38":39,"_28":73,"_41":756,"_43":757},{},[758],"delete_all"," uses a SQL query, it’s not going to instantiate the dependent records and run the delete callbacks.",["SingleFetchClassInstance",761],{"_38":39,"_28":40,"_41":762,"_43":763},{},[764,765,770,771,707],"To ensure the callbacks are run, we’d change the ",["SingleFetchClassInstance",766],{"_38":39,"_28":73,"_41":767,"_43":768},{},[769],"dependent"," option to ",["SingleFetchClassInstance",772],{"_38":39,"_28":73,"_41":773,"_43":774},{},[775],"destroy",["SingleFetchClassInstance",777],{"_38":39,"_28":92,"_41":778,"_43":780},{"_94":779,"_96":97},"

class Order < ApplicationRecord\n  has_many :invoices, dependent: :destroy\nend\n

",[],["SingleFetchClassInstance",782],{"_38":39,"_28":40,"_41":783,"_43":784},{},[785,786,791],"Deleting an order now instantiates each dependent, and associated record and calls ",["SingleFetchClassInstance",787],{"_38":39,"_28":73,"_41":788,"_43":789},{},[790],"#destroy"," on it.",["SingleFetchClassInstance",793],{"_38":39,"_28":40,"_41":794,"_43":795},{},[796],"But what happens if there are tens, hundreds, or even thousands of associated records? It means tens, hundreds, or even thousands of object instantiations and SQL calls.",["SingleFetchClassInstance",798],{"_38":39,"_28":40,"_41":799,"_43":800},{},[801,802,807],"This long-running functionality ",["SingleFetchClassInstance",803],{"_38":39,"_28":149,"_41":804,"_43":805},{},[806],"feels"," like something that could run in a background job. As it turns out, Rails agrees.",["SingleFetchClassInstance",809],{"_38":39,"_28":40,"_41":810,"_43":811},{},[812,813,818,819,824],"Changing the ",["SingleFetchClassInstance",814],{"_38":39,"_28":73,"_41":815,"_43":816},{},[817],"dependent: :destroy"," to ",["SingleFetchClassInstance",820],{"_38":39,"_28":73,"_41":821,"_43":822},{},[823],"dependent: :destroy_async"," will enqueue a background job to destroy the dependent, associated records.",["SingleFetchClassInstance",826],{"_38":39,"_28":40,"_41":827,"_43":828},{},[829,830,835,836,84],"It’s worth noting this only works for associations that do ",["SingleFetchClassInstance",831],{"_38":39,"_28":149,"_41":832,"_43":833},{},[834],"not"," have a foreign key constraint. For more options for destroying dependent relations, take a look at the ",["SingleFetchClassInstance",837],{"_38":39,"_28":60,"_41":838,"_43":840},{"_62":839},"https://github.com/sutrolabs/miss_hannigan",[841],"Miss Hannigan gem",["SingleFetchClassInstance",843],{"_38":39,"_28":40,"_41":844,"_43":845},{},[846,847,853],"We have another post on ",["SingleFetchClassInstance",848],{"_38":39,"_28":60,"_41":849,"_43":851},{"_62":850},"/blog/ruby-on-rails-3-tips-for-deleting-data-at-scale",[852],"deleting data at scale with Rails"," if you want to dig in deeper.",["SingleFetchClassInstance",855],{"_38":39,"_28":53,"_41":856,"_43":858},{"_55":857},"fail-loudly-fail-proudly",[859],["SingleFetchClassInstance",860],{"_38":39,"_28":60,"_41":861,"_43":863},{"_62":862},"#fail-loudly-fail-proudly",[864],"Fail loudly, fail proudly",["SingleFetchClassInstance",866],{"_38":39,"_28":40,"_41":867,"_43":868},{},[869,870,875,876,84],"Active Record methods fail ",["SingleFetchClassInstance",871],{"_38":39,"_28":80,"_41":872,"_43":873},{},[874],"loudly"," or ",["SingleFetchClassInstance",877],{"_38":39,"_28":80,"_41":878,"_43":879},{},[880],"silently",["SingleFetchClassInstance",882],{"_38":39,"_28":40,"_41":883,"_43":884},{},[885,886,891],"You can often tell if an Active Record method fails loudly or silently by its name. Most (not all) methods that end with a bang (",["SingleFetchClassInstance",887],{"_38":39,"_28":73,"_41":888,"_43":889},{},[890],"!",") will raise an error. What’s the difference?",["SingleFetchClassInstance",893],{"_38":39,"_28":218,"_41":894,"_43":896},{"_55":895},"loud-failures",[897],["SingleFetchClassInstance",898],{"_38":39,"_28":60,"_41":899,"_43":901},{"_62":900},"#loud-failures",[902],"Loud failures",["SingleFetchClassInstance",904],{"_38":39,"_28":40,"_41":905,"_43":906},{},[907],"Loud failures raise an error and halt code execution.",["SingleFetchClassInstance",909],{"_38":39,"_28":40,"_41":910,"_43":911},{},[912,913,918,919,924],"A good example of this is Active Record’s ",["SingleFetchClassInstance",914],{"_38":39,"_28":73,"_41":915,"_43":916},{},[917],".find"," method which locates the database record by ID. Trying to find a record that doesn’t exist raises an ",["SingleFetchClassInstance",920],{"_38":39,"_28":73,"_41":921,"_43":922},{},[923],"ActiveRecord::RecordNotFound"," error.",["SingleFetchClassInstance",926],{"_38":39,"_28":92,"_41":927,"_43":929},{"_94":928,"_96":97},"

class OrdersController < ApplicationController\n  def update\n    @order = Order.find(params[:non_existent_id]\n\n    @order.update(order_params)\n  end\nend\n

",[],["SingleFetchClassInstance",931],{"_38":39,"_28":40,"_41":932,"_43":933},{},[934],"We never get to the update call because the lookup raises an error and halts the request.",["SingleFetchClassInstance",936],{"_38":39,"_28":218,"_41":937,"_43":939},{"_55":938},"silent-failures",[940],["SingleFetchClassInstance",941],{"_38":39,"_28":60,"_41":942,"_43":944},{"_62":943},"#silent-failures",[945],"Silent failures",["SingleFetchClassInstance",947],{"_38":39,"_28":40,"_41":948,"_43":949},{},[950,951,955,956,961],"Instead of using ",["SingleFetchClassInstance",952],{"_38":39,"_28":73,"_41":953,"_43":954},{},[917],", replace it with ",["SingleFetchClassInstance",957],{"_38":39,"_28":73,"_41":958,"_43":959},{},[960],".find_by",", which takes a list of attributes to look up instead of an ID.",["SingleFetchClassInstance",963],{"_38":39,"_28":92,"_41":964,"_43":966},{"_94":965,"_96":97},"

class OrdersController < ApplicationController\n  def update\n    @order = Order.find_by(id: params[:non_existent_id]\n\n    @order.update(order_params)\n  end\nend\n

",[],["SingleFetchClassInstance",968],{"_38":39,"_28":40,"_41":969,"_43":970},{},[971,972,976,977,982,983,988,989,994],"In this case, ",["SingleFetchClassInstance",973],{"_38":39,"_28":73,"_41":974,"_43":975},{},[960]," returns nil. This means we’ll get to the ",["SingleFetchClassInstance",978],{"_38":39,"_28":73,"_41":979,"_43":980},{},[981],"#update"," action, but it will try to call ",["SingleFetchClassInstance",984],{"_38":39,"_28":73,"_41":985,"_43":986},{},[987],"update"," on ",["SingleFetchClassInstance",990],{"_38":39,"_28":73,"_41":991,"_43":992},{},[993],"nil",", which will raise the ever-present “undefined method x for nil.” 🥶",["SingleFetchClassInstance",996],{"_38":39,"_28":218,"_41":997,"_43":999},{"_55":998},"comparing-the-two",[1000],["SingleFetchClassInstance",1001],{"_38":39,"_28":60,"_41":1002,"_43":1004},{"_62":1003},"#comparing-the-two",[1005],"Comparing the two",["SingleFetchClassInstance",1007],{"_38":39,"_28":40,"_41":1008,"_43":1009},{},[1010],"In this example, we create an order and notification. Once we’re done creating records, we send a notification email.",["SingleFetchClassInstance",1012],{"_38":39,"_28":92,"_41":1013,"_43":1015},{"_94":1014,"_96":97},"

order = Order.create(order_params)\n\nnotification = Notification.create(notifiable: order)\n\nNotificationEmail.deliver_later(notification)\n

",[],["SingleFetchClassInstance",1017],{"_38":39,"_28":40,"_41":1018,"_43":1019},{},[1020],"What happens if creating the notification fails validation?",["SingleFetchClassInstance",1022],{"_38":39,"_28":40,"_41":1023,"_43":1024},{},[1025,1026,1031,1032,1037],"We get an instance of ",["SingleFetchClassInstance",1027],{"_38":39,"_28":73,"_41":1028,"_43":1029},{},[1030],"Notification"," back that isn’t in the database. The notification is passed to the ",["SingleFetchClassInstance",1033],{"_38":39,"_28":73,"_41":1034,"_43":1035},{},[1036],"NotificationEmail"," and sent in the background.",["SingleFetchClassInstance",1039],{"_38":39,"_28":40,"_41":1040,"_43":1041},{},[1042],"This block of code doesn’t fail. But when the job runs later, in the background, it fails. The notification can’t be retrieved from the database because it was never saved to the database. 😅",["SingleFetchClassInstance",1044],{"_38":39,"_28":630,"_41":1045,"_43":1047},{"_55":1046},"silently-failing",[1048],["SingleFetchClassInstance",1049],{"_38":39,"_28":60,"_41":1050,"_43":1052},{"_62":1051},"#silently-failing",[1053],"Silently failing",["SingleFetchClassInstance",1055],{"_38":39,"_28":40,"_41":1056,"_43":1057},{},[1058,1059,1064],"If we acknowledge it’s okay for a notification to fail, we can continue using the silent failure, ",["SingleFetchClassInstance",1060],{"_38":39,"_28":73,"_41":1061,"_43":1062},{},[1063],"create",", and add a boundary:",["SingleFetchClassInstance",1066],{"_38":39,"_28":92,"_41":1067,"_43":1069},{"_94":1068,"_96":97},"

notification = Notification.create(notifiable: order)\n\nif notification.valid?\n  NotificationEmail.deliver_later(notification)\nend\n

",[],["SingleFetchClassInstance",1071],{"_38":39,"_28":630,"_41":1072,"_43":1074},{"_55":1073},"failing-loudly",[1075],["SingleFetchClassInstance",1076],{"_38":39,"_28":60,"_41":1077,"_43":1079},{"_62":1078},"#failing-loudly",[1080],"Failing loudly!",["SingleFetchClassInstance",1082],{"_38":39,"_28":40,"_41":1083,"_43":1084},{},[1085],"But often times I don’t expect code to fail. If it is failing, it’s a signal of a larger problem that should be addressed.",["SingleFetchClassInstance",1087],{"_38":39,"_28":40,"_41":1088,"_43":1089},{},[1090],"In our example, the background job failing wasn’t the root issue. It was a side effect. If we don’t expect creating a notification to ever fail, failing loudly might be a good option.",["SingleFetchClassInstance",1092],{"_38":39,"_28":40,"_41":1093,"_43":1094},{},[1095,1096,707],"In this example, failing loudly is done by using ",["SingleFetchClassInstance",1097],{"_38":39,"_28":73,"_41":1098,"_43":1099},{},[1100],"create!",["SingleFetchClassInstance",1102],{"_38":39,"_28":92,"_41":1103,"_43":1105},{"_94":1104,"_96":97},"

notification = Noficiation.create!(notifiable: order)\nNotification.deliver_later(notification)\n

",[],["SingleFetchClassInstance",1107],{"_38":39,"_28":40,"_41":1108,"_43":1109},{},[1110],"This juicy code block raises an error if validation fails and makes it easier to track.",["SingleFetchClassInstance",1112],{"_38":39,"_28":40,"_41":1113,"_43":1114},{},[1115,1116,1121],"If the job is failing because the notification wasn’t created, we have to figure out what enqueued the job ",["SingleFetchClassInstance",1117],{"_38":39,"_28":149,"_41":1118,"_43":1119},{},[1120],"and"," why it failed.",["SingleFetchClassInstance",1123],{"_38":39,"_28":40,"_41":1124,"_43":1125},{},[1126,1127,1131,1132,1136,1137],"If an error is raised because the ",["SingleFetchClassInstance",1128],{"_38":39,"_28":73,"_41":1129,"_43":1130},{},[1030]," failed to create, the job is never enqueued ",["SingleFetchClassInstance",1133],{"_38":39,"_28":149,"_41":1134,"_43":1135},{},[1120]," we immediately know where to look to fix the problem. ",["SingleFetchClassInstance",1138],{"_38":39,"_28":80,"_41":1139,"_43":1140},{},[1141],"The error itself signals what went wrong.",["SingleFetchClassInstance",1143],{"_38":39,"_28":53,"_41":1144,"_43":1146},{"_55":1145},"credential-protection-in-rails",[1147],["SingleFetchClassInstance",1148],{"_38":39,"_28":60,"_41":1149,"_43":1151},{"_62":1150},"#credential-protection-in-rails",[1152],"Credential protection in Rails",["SingleFetchClassInstance",1154],{"_38":39,"_28":40,"_41":1155,"_43":1156},{},[1157],"I once got a bill from AWS for $20,000+. Want to guess what happened?",["SingleFetchClassInstance",1159],{"_38":39,"_28":40,"_41":1160,"_43":1161},{},[1162,1163,1168],"My ",["SingleFetchClassInstance",1164],{"_38":39,"_28":149,"_41":1165,"_43":1166},{},[1167],"private"," git repo was compromised where I had hard-coded AWS credentials. That day I learned about the importance of keeping credentials out of your code.",["SingleFetchClassInstance",1170],{"_38":39,"_28":40,"_41":1171,"_43":1172},{},[1173],"We often store credentials as environment variables. Whenever we add a new credential, we update all the places our application runs: production, CI, the password manager team shares, etc.",["SingleFetchClassInstance",1175],{"_38":39,"_28":40,"_41":1176,"_43":1177},{},[1178],"What if I told you Rails has a built-in mechanism for securely storing credentials?",["SingleFetchClassInstance",1180],{"_38":39,"_28":218,"_41":1181,"_43":1183},{"_55":1182},"rails-credentials",[1184],["SingleFetchClassInstance",1185],{"_38":39,"_28":60,"_41":1186,"_43":1188},{"_62":1187},"#rails-credentials",[1189],"Rails credentials",["SingleFetchClassInstance",1191],{"_38":39,"_28":40,"_41":1192,"_43":1193},{},[1194,1195,1200],"Instead of keeping environment variables in sync across multiple developers and platforms, we can store our credentials ",["SingleFetchClassInstance",1196],{"_38":39,"_28":149,"_41":1197,"_43":1198},{},[1199],"securely"," in our application.",["SingleFetchClassInstance",1202],{"_38":39,"_28":40,"_41":1203,"_43":1204},{},[1205],"To get started, run the Rails CLI:",["SingleFetchClassInstance",1207],{"_38":39,"_28":92,"_41":1208,"_43":1211},{"_94":1209,"_96":1210},"

bin/rails credentials:edit --environment=development\n

","bash",[],["SingleFetchClassInstance",1213],{"_38":39,"_28":40,"_41":1214,"_43":1215},{},[1216],"The first time this command is run it creates two files:",["SingleFetchClassInstance",1218],{"_38":39,"_28":1219,"_41":1220,"_43":1221},"ol",{},[1222,1232],["SingleFetchClassInstance",1223],{"_38":39,"_28":1224,"_41":1225,"_43":1226},"li",{},[1227],["SingleFetchClassInstance",1228],{"_38":39,"_28":73,"_41":1229,"_43":1230},{},[1231],"config/credentials/development.yml.enc",["SingleFetchClassInstance",1233],{"_38":39,"_28":1224,"_41":1234,"_43":1235},{},[1236],["SingleFetchClassInstance",1237],{"_38":39,"_28":73,"_41":1238,"_43":1239},{},[1240],"config/credentials/development.key",["SingleFetchClassInstance",1242],{"_38":39,"_28":40,"_41":1243,"_43":1244},{},[1245],"The first file is an encrypted YAML file. When we ran our command, the file was temporarily decrypted and opened in our editor for us to edit.",["SingleFetchClassInstance",1247],{"_38":39,"_28":40,"_41":1248,"_43":1249},{},[1250],"While the file is decrypted, we can update it to store our credentials in a standard YAML key/value structure:",["SingleFetchClassInstance",1252],{"_38":39,"_28":92,"_41":1253,"_43":1255},{"_94":1254,"_96":97},"

stripe:\n  secret_key: SK1234\n  publishable_key: PK1234\n

",[],["SingleFetchClassInstance",1257],{"_38":39,"_28":40,"_41":1258,"_43":1259},{},[1260,1261,1266],"Once we close the file, it’s re-encrypted. The file can be decrypted only with the key it was encrypted with, which was the second file created. Rails adds the decryption keys to ",["SingleFetchClassInstance",1262],{"_38":39,"_28":73,"_41":1263,"_43":1264},{},[1265],".gitignore",", keeping it from accidentally being committed to git.",["SingleFetchClassInstance",1268],{"_38":39,"_28":40,"_41":1269,"_43":1270},{},[1271],"Once our secrets are saved, we can access them in the app using the following:",["SingleFetchClassInstance",1273],{"_38":39,"_28":92,"_41":1274,"_43":1276},{"_94":1275,"_96":97},"

Rails.application.credentials.stripe.secret_key\nRails.application.credentials.stripe.publishable_key\n

",[],["SingleFetchClassInstance",1278],{"_38":39,"_28":40,"_41":1279,"_43":1280},{},[1281],["SingleFetchClassInstance",1282],{"_38":39,"_28":141,"_41":1283,"_43":1284},{"_143":144},[1285,1286,1291]," 🚨 ",["SingleFetchClassInstance",1287],{"_38":39,"_28":80,"_41":1288,"_43":1289},{},[1290],"Keep the key that Rails generated safe! If you lose it, you’ll lose access to your credentials."," If you work on a team, keep it somewhere safe, like a password manager. ",["SingleFetchClassInstance",1293],{"_38":39,"_28":630,"_41":1294,"_43":1296},{"_55":1295},"multiple-environments",[1297],["SingleFetchClassInstance",1298],{"_38":39,"_28":60,"_41":1299,"_43":1301},{"_62":1300},"#multiple-environments",[1302],"Multiple environments",["SingleFetchClassInstance",1304],{"_38":39,"_28":40,"_41":1305,"_43":1306},{},[1307,1308,1312],"In the example above, I used the ",["SingleFetchClassInstance",1309],{"_38":39,"_28":73,"_41":1310,"_43":1311},{},[7]," environment. Rails is going to automatically defer to the development set of credentials in development.",["SingleFetchClassInstance",1314],{"_38":39,"_28":40,"_41":1315,"_43":1316},{},[1317],"I create a credentials file for each environment: development, staging, and production. This makes it easy to keep development and production credentials separate.",["SingleFetchClassInstance",1319],{"_38":39,"_28":53,"_41":1320,"_43":1322},{"_55":1321},"development-emails-in-rails",[1323],["SingleFetchClassInstance",1324],{"_38":39,"_28":60,"_41":1325,"_43":1327},{"_62":1326},"#development-emails-in-rails",[1328],"Development emails in Rails",["SingleFetchClassInstance",1330],{"_38":39,"_28":40,"_41":1331,"_43":1332},{},[1333],"What’s more fun than using real email addresses in development? Accidentally sending emails to those real email addresses in development. 😎",["SingleFetchClassInstance",1335],{"_38":39,"_28":40,"_41":1336,"_43":1337},{},[1338],"(While we’re here… please don’t send emails from Active Record callbacks.)",["SingleFetchClassInstance",1340],{"_38":39,"_28":40,"_41":1341,"_43":1342},{},[1343,1344,875,1350,1356],"While tools exist to make this experience better (",["SingleFetchClassInstance",1345],{"_38":39,"_28":60,"_41":1346,"_43":1348},{"_62":1347},"https://github.com/ryanb/letter_opener",[1349],"Letter Opener",["SingleFetchClassInstance",1351],{"_38":39,"_28":60,"_41":1352,"_43":1354},{"_62":1353},"https://mailtrap.io",[1355],"Mailtrap","), Rails provides a few mechanisms to help.",["SingleFetchClassInstance",1358],{"_38":39,"_28":218,"_41":1359,"_43":1361},{"_55":1360},"turn-off-email-delivery",[1362],["SingleFetchClassInstance",1363],{"_38":39,"_28":60,"_41":1364,"_43":1366},{"_62":1365},"#turn-off-email-delivery",[1367],"Turn off email delivery",["SingleFetchClassInstance",1369],{"_38":39,"_28":40,"_41":1370,"_43":1371},{},[1372,1373,707],"This is the least exciting yet most effective mechanism for preventing unwanted emails from being sent. To turn off email delivery, add the following setting to ",["SingleFetchClassInstance",1374],{"_38":39,"_28":73,"_41":1375,"_43":1376},{},[649],["SingleFetchClassInstance",1378],{"_38":39,"_28":92,"_41":1379,"_43":1381},{"_94":1380,"_96":97},"

config.action_mailer.perform_deliveries = false\n

",[],["SingleFetchClassInstance",1383],{"_38":39,"_28":40,"_41":1384,"_43":1385},{},[1386],"This option may be suitable if you have email previews and a solid test suite.",["SingleFetchClassInstance",1388],{"_38":39,"_28":218,"_41":1389,"_43":1391},{"_55":1390},"change-the-delivery-method",[1392],["SingleFetchClassInstance",1393],{"_38":39,"_28":60,"_41":1394,"_43":1396},{"_62":1395},"#change-the-delivery-method",[1397],"Change the delivery method",["SingleFetchClassInstance",1399],{"_38":39,"_28":40,"_41":1400,"_43":1401},{},[1402],"Maybe you want to have a record of the email being sent for debugging. Action Mailer can save “sent” emails as files instead of delivering them.",["SingleFetchClassInstance",1404],{"_38":39,"_28":40,"_41":1405,"_43":1406},{},[1407,1408,707],"To do this, add the following setting to ",["SingleFetchClassInstance",1409],{"_38":39,"_28":73,"_41":1410,"_43":1411},{},[649],["SingleFetchClassInstance",1413],{"_38":39,"_28":92,"_41":1414,"_43":1416},{"_94":1415,"_96":97},"

config.action_mailer.deliver_method = :file\n

",[],["SingleFetchClassInstance",1418],{"_38":39,"_28":40,"_41":1419,"_43":1420},{},[1421,1422,1427],"Any emails “sent” from the application in development will be saved to ",["SingleFetchClassInstance",1423],{"_38":39,"_28":73,"_41":1424,"_43":1425},{},[1426],"tmp/mails",". This saves the raw output, which might be enough for your use case.",["SingleFetchClassInstance",1429],{"_38":39,"_28":40,"_41":1430,"_43":1431},{},[1432],"For me, though, I typically want to see the email in its final, table-loaded, CSS-less, 1990s HTML email form.",["SingleFetchClassInstance",1434],{"_38":39,"_28":218,"_41":1435,"_43":1437},{"_55":1436},"email-interceptors",[1438],["SingleFetchClassInstance",1439],{"_38":39,"_28":60,"_41":1440,"_43":1442},{"_62":1441},"#email-interceptors",[1443],"Email interceptors",["SingleFetchClassInstance",1445],{"_38":39,"_28":40,"_41":1446,"_43":1447},{},[1448],"The final option we’ll look at is intercepting all emails sent in development and rerouting them to your email address. This only works if you have an active SMTP server or email provider configured in development mode.",["SingleFetchClassInstance",1450],{"_38":39,"_28":40,"_41":1451,"_43":1452},{},[1453],"We do this by defining an email interceptor:",["SingleFetchClassInstance",1455],{"_38":39,"_28":92,"_41":1456,"_43":1458},{"_94":1457,"_96":97},"

class DevelopmentEmailInterceptor\n  def self.delivering_email(message)\n    message.to = [\"jason@example.com\"]\n  end\nend\n

",[],["SingleFetchClassInstance",1460],{"_38":39,"_28":40,"_41":1461,"_43":1462},{},[1463,1464,1469],"The email interceptor implements the ",["SingleFetchClassInstance",1465],{"_38":39,"_28":73,"_41":1466,"_43":1467},{},[1468],".delivering_email"," method. Inside the method, we’ll change the message’s recipient to our email address.",["SingleFetchClassInstance",1471],{"_38":39,"_28":40,"_41":1472,"_43":1473},{},[1474,1475,707],"To wire up the interceptor, we add the following option to ",["SingleFetchClassInstance",1476],{"_38":39,"_28":73,"_41":1477,"_43":1478},{},[649],["SingleFetchClassInstance",1480],{"_38":39,"_28":92,"_41":1481,"_43":1483},{"_94":1482,"_96":97},"

config.action_mailer.interceptors = [\"DevelopmentEmailInterceptor\"]\n

",[],["SingleFetchClassInstance",1485],{"_38":39,"_28":40,"_41":1486,"_43":1487},{},[1488],"Now, any email sent from development will be rerouted to our email, no matter who it was initially addressed to.",["SingleFetchClassInstance",1490],{"_38":39,"_28":53,"_41":1491,"_43":1493},{"_55":1492},"stay-safe",[1494],["SingleFetchClassInstance",1495],{"_38":39,"_28":60,"_41":1496,"_43":1498},{"_62":1497},"#stay-safe",[1499],"Stay safe",["SingleFetchClassInstance",1501],{"_38":39,"_28":40,"_41":1502,"_43":1503},{},[1504],"These tools give us more confidence in building our applications.",["SingleFetchClassInstance",1506],{"_38":39,"_28":40,"_41":1507,"_43":1508},{},[1509],"Having Rails raise an error every time you forget to include an association may feel like a minor annoyance. But it’s less annoying than having to revisit code a few months later to fix a performance issue a preload would have avoided.",["SingleFetchClassInstance",1511],{"_38":39,"_28":40,"_41":1512,"_43":1513},{},[1514],"Having to add the boilerplate strong parameters requires may feel boring. But give me boring over the excitement of a bad actor creating a security incident for my customers.",["SingleFetchClassInstance",1516],{"_38":39,"_28":40,"_41":1517,"_43":1518},{},[1519],"Go enjoy the vast magic of Rails, my friends.","body_text","Companies build products with Ruby on Rails because of its focus on efficiency. The framework comes with a set of defaults that allows you to focus on building, not configuring.\nDefaults can have limits. We can often find ourselves with paper cuts if we’re not careful. Fear not! Rails has conventions for this, too. Let’s look at some tools the framework gives us to protect ourselves.\nMass assignment protection in Rails\nOne of the first things Rails developers learn is handling form parameters. The params object contains all the form parameters for us to use in controllers and views. But whenever Rails generates a scaffold it uses something called strong parameters.\nWhat are strong parameters, exactly? When creating or updating an Active Record model we can pass an optional hash of attributes.User.create(name: \"Jason Charnes\", location: \"Memphis\")`\n\nThis pairs beautifully with the Rails form helpers:<%= form_with model: @user do |form| %>\n <%= form.text_field :name %>\n <%= form.text_field :location %>\n <%= form.submit %>\n<% end %>\n\nThe parameters sent from the form to the controller look like this:{user: {name: \"Jason Charnes\", location: \"Memphis\"}}\n\nWe can pass the user hash directly:class UsersController < ApplicationController\n def create\n User.create!(params[:user])\n end\nend\n\n🚨 This is mass assignment; it’s dangerous.\nWhile creating the record, we’re mass assigning the attributes. This is simple, clean, and appears to work great, but there’s a problem.\nThe User model also has an admin boolean that defaults to false. What if our end-user is sneaky and adds this to the form?\n\nNow the params look like this:{user: {name: \"Jason Charnes\", location: \"Memphis\", admin: \"true\"}}\n\nWe’re passing the entire list of parameters to Active Record, including admin.class UsersController < ApplicationController\n def create\n @user = User.create!(params[:user])\n @user.admin? #=> true\n end\nend\n\nYikes, we gave away the keys to the kingdom. This is the role strong parameters play.\nStrong parameters\nInstead of mass assignment (passing the raw params directly to Active Record), we use strong parameters to signal which attributes are allowed.class UsersController < ApplicationController\n def create\n User.create!(user_params)\n end\n\n private\n\n def user_params\n params.require(:user).permit(:name)\n end\nend\n\nHere, we define a user_params method that is responsible for allowing specific parameters through.\nWe start by telling the params object that we require the parameters to have a key of :user. If the params don’t have this key, an error is raised and the request is halted.\nFrom there we provide a list of permitted attributes to the permit method.\nNow, if our end-user tries to pass admin as a parameter, Rails will exclude it from the list of params passed to Active Record.\nRails will log unpermitted parameters by default. This is useful for debugging in development and looking for bad actors in production. If you want to take things further, you can tell Rails to raise an error if unpermitted parameters are passed:config.action_controller.action_on_unpermitted_parameters = :raise\n\nStrong parameters are a controller-level feature. Is there a way to enforce this in the model? Rails doesn’t provide this, but it used to.\nBefore the introduction of strong parameters in Rails 4, mass assignment protection happened at the model level. (Does anyone remember attr_protected and attr_accessible?!)\nThe strong parameters pattern is more flexible. You likely want to permit different attributes depending on the context. A user shouldn’t set their admin status. But an existing admin may be able to set it.\nWhile it’s easier to define it in the model, it’s simpler to let the controller do it.\nN+1 prevention in Rails\nN+1 queries are unfortunately easy to perform in Active Record. ✨\nIf we access an association we haven’t loaded, Rails will make the database lookup on our behalf. Rails has our back here. It comes at a cost, though. (Unless you view N+1s as a feature.)\nPretend we’re rendering a list of orders:class OrdersController < ApplicationController\n def index\n @orders = Order.all\n end\nend\n<% @orders.each do |order| %>\n \n <%= order.id %>\n <%= order.customer.name %>\n <%= order.created_at %>\n \n<% end %>\n\nWe’re rendering the customer’s name on each order. An order belongs to a customer.class Order < ApplicationRecord\n belongs_to :customer\nend\n\nWe didn’t ask the database for customers, though. Just orders. The logs show the single database query for orders. ✅SELECT \"orders\".* FROM \"orders\"\n\nAnd a customers table query for each order we rendered. ❌SELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 1], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 2], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 3], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 4], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 5], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 6], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 7], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 8], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 9], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 10], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 11], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 12], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 13], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 14], [\"LIMIT\", 1]]\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" = $1 LIMIT $2 [[\"id\", 15], [\"LIMIT\", 1]]\n\nRails knows customers aren’t loaded, so it lazy loads (does a database lookup for) each customer on the fly.\nThe query returns 15 orders, which means 15 individual customer queries. This is what I mean by N+1. We have N order records. For every order, we have +1 more query to look up the customer.\nThis is a problem when working with large datasets.\nEach request to the customers table isn’t necessarily a bottleneck — they’re pretty quick. But they add up. And sometimes it’s not just one association per record. It’s many associations per record.\nThe solution to N+1s\nWe fix this by preloading associations.class OrdersController < ApplicationController\n def index\n @orders = Order.includes(:customer).all\n end\nend\n\nBy adding the .includes method with the association we want to preload, Rails ensures that every corresponding customer is loaded.\nInstead of 15 extra SQL queries, we only have 1 extra query:SELECT \"orders\".* FROM \"orders\"\n\nSELECT \"customers\".* FROM \"customers\" WHERE \"customers\".\"id\" IN ($1, $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15) [[\"id\", 1], [\"id\", 2], [\"id\", 3], [\"id\", 4], [\"id\", 5], [\"id\", 6], [\"id\", 7], [\"id\", 8], [\"id\", 9], [\"id\", 10], [\"id\", 11], [\"id\", 12], [\"id\", 13], [\"id\", 14], [\"id\", 15]]\n\nOver time it’s easier to know when you’re introducing an N+1 query, but it’s still easy to miss them. Let’s look at how we can catch N+1s before shipping to production.\nBefore Rails 6.1\nThe Bullet gem is the tool for discovering N+1s.\nBullet keeps an eye out for N+1 queries in your application. From Rails logs to notifying you in Slack, it has many ways to warn you of N+1 queries.\nRemember, it’s still up to you to listen and fix the N+1s. 😅\nRails 6.1+\nIf you don’t want to fool with another dependency or know that you’ll just ignore Bullet warning you of N+1s, there’s a more invasive option.\nRails 6.1 introduced a mechanism for detecting down N+1s: strict_loading.class Order < ApplicationRecord\n belongs_to :customer, strict_loading: true\nend\n\nAdding this option to the customer association results in an ActiveRecord::StrictLoadingViolationError raised if Rails detects you’re lazy loading the association.\nWhen we encounter this error, it’s clear to us what happened:`Order` is marked for strict_loading. The Customer association named `:customer` cannot be lazily loaded.\n\nAdding this option to each association is tedious! Luckily, there’s a way to enable this functionality globally.\nApplying strict loading in development\nIf you only want an error raised in development, not production, you can enable the option in config/development.rbconfig.active_record.strict_loading_by_default = true\n\nI like Aaron Francis’ idea of enforcing strict loading in development only. In our companion article on Laravel’s safety mechanisms, he suggests:\nLazy loading relationships does not affect the correctness of your application, merely the performance of it. Ideally, all the relations you need are eager loaded, but if not, it simply falls through and lazy loads the required relationships.\nFor that reason, we recommend disallowing lazy loading in every environment except production. Hopefully, all lazy loads will be caught in local development or testing, but in the rare case that a lazy load makes its way into production, your app will continue to work just fine, if a bit slower.\nApplying strict loading regardless of the environment\nIf performance is critical and it’s important to raise this error in all environments, including production, apply the option in config/application.rb:config.active_record.strict_loading_by_default = true\n\nAsynchronous association destruction\nActive Record provides a mechanism for deleting associated records when a parent record is deleted.\nThe quickest, simplest way to delete dependent data is by providing the dependent: :delete_all option on the association:class Order < ApplicationRecord\n has_many :invoices, dependent: :delete_all\nend\n\nDeleting this order will execute a separate, single SQL query to delete all the associated invoices.\nSometimes, though, the dependent records have “on delete” callbacks that need to run. Because delete_all uses a SQL query, it’s not going to instantiate the dependent records and run the delete callbacks.\nTo ensure the callbacks are run, we’d change the dependent option to destroy:class Order < ApplicationRecord\n has_many :invoices, dependent: :destroy\nend\n\nDeleting an order now instantiates each dependent, and associated record and calls #destroy on it.\nBut what happens if there are tens, hundreds, or even thousands of associated records? It means tens, hundreds, or even thousands of object instantiations and SQL calls.\nThis long-running functionality feels like something that could run in a background job. As it turns out, Rails agrees.\nChanging the dependent: :destroy to dependent: :destroy_async will enqueue a background job to destroy the dependent, associated records.\nIt’s worth noting this only works for associations that do not have a foreign key constraint. For more options for destroying dependent relations, take a look at the Miss Hannigan gem.\nWe have another post on deleting data at scale with Rails if you want to dig in deeper.\nFail loudly, fail proudly\nActive Record methods fail loudly or silently.\nYou can often tell if an Active Record method fails loudly or silently by its name. Most (not all) methods that end with a bang (!) will raise an error. What’s the difference?\nLoud failures\nLoud failures raise an error and halt code execution.\nA good example of this is Active Record’s .find method which locates the database record by ID. Trying to find a record that doesn’t exist raises an ActiveRecord::RecordNotFound error.class OrdersController < ApplicationController\n def update\n @order = Order.find(params[:non_existent_id]\n\n @order.update(order_params)\n end\nend\n\nWe never get to the update call because the lookup raises an error and halts the request.\nSilent failures\nInstead of using .find, replace it with .find_by, which takes a list of attributes to look up instead of an ID.class OrdersController < ApplicationController\n def update\n @order = Order.find_by(id: params[:non_existent_id]\n\n @order.update(order_params)\n end\nend\n\nIn this case, .find_by returns nil. This means we’ll get to the #update action, but it will try to call update on nil, which will raise the ever-present “undefined method x for nil.” 🥶\nComparing the two\nIn this example, we create an order and notification. Once we’re done creating records, we send a notification email.order = Order.create(order_params)\n\nnotification = Notification.create(notifiable: order)\n\nNotificationEmail.deliver_later(notification)\n\nWhat happens if creating the notification fails validation?\nWe get an instance of Notification back that isn’t in the database. The notification is passed to the NotificationEmail and sent in the background.\nThis block of code doesn’t fail. But when the job runs later, in the background, it fails. The notification can’t be retrieved from the database because it was never saved to the database. 😅\nSilently failing\nIf we acknowledge it’s okay for a notification to fail, we can continue using the silent failure, create, and add a boundary:notification = Notification.create(notifiable: order)\n\nif notification.valid?\n NotificationEmail.deliver_later(notification)\nend\n\nFailing loudly!\nBut often times I don’t expect code to fail. If it is failing, it’s a signal of a larger problem that should be addressed.\nIn our example, the background job failing wasn’t the root issue. It was a side effect. If we don’t expect creating a notification to ever fail, failing loudly might be a good option.\nIn this example, failing loudly is done by using create!:notification = Noficiation.create!(notifiable: order)\nNotification.deliver_later(notification)\n\nThis juicy code block raises an error if validation fails and makes it easier to track.\nIf the job is failing because the notification wasn’t created, we have to figure out what enqueued the job and why it failed.\nIf an error is raised because the Notification failed to create, the job is never enqueued and we immediately know where to look to fix the problem. The error itself signals what went wrong.\nCredential protection in Rails\nI once got a bill from AWS for $20,000+. Want to guess what happened?\nMy private git repo was compromised where I had hard-coded AWS credentials. That day I learned about the importance of keeping credentials out of your code.\nWe often store credentials as environment variables. Whenever we add a new credential, we update all the places our application runs: production, CI, the password manager team shares, etc.\nWhat if I told you Rails has a built-in mechanism for securely storing credentials?\nRails credentials\nInstead of keeping environment variables in sync across multiple developers and platforms, we can store our credentials securely in our application.\nTo get started, run the Rails CLI:bin/rails credentials:edit --environment=development\n\nThe first time this command is run it creates two files:\nconfig/credentials/development.yml.enc\nconfig/credentials/development.key\nThe first file is an encrypted YAML file. When we ran our command, the file was temporarily decrypted and opened in our editor for us to edit.\nWhile the file is decrypted, we can update it to store our credentials in a standard YAML key/value structure:stripe:\n secret_key: SK1234\n publishable_key: PK1234\n\nOnce we close the file, it’s re-encrypted. The file can be decrypted only with the key it was encrypted with, which was the second file created. Rails adds the decryption keys to .gitignore, keeping it from accidentally being committed to git.\nOnce our secrets are saved, we can access them in the app using the following:Rails.application.credentials.stripe.secret_key\nRails.application.credentials.stripe.publishable_key\n\n 🚨 Keep the key that Rails generated safe! If you lose it, you’ll lose access to your credentials. If you work on a team, keep it somewhere safe, like a password manager. \nMultiple environments\nIn the example above, I used the development environment. Rails is going to automatically defer to the development set of credentials in development.\nI create a credentials file for each environment: development, staging, and production. This makes it easy to keep development and production credentials separate.\nDevelopment emails in Rails\nWhat’s more fun than using real email addresses in development? Accidentally sending emails to those real email addresses in development. 😎\n(While we’re here… please don’t send emails from Active Record callbacks.)\nWhile tools exist to make this experience better (Letter Opener or Mailtrap), Rails provides a few mechanisms to help.\nTurn off email delivery\nThis is the least exciting yet most effective mechanism for preventing unwanted emails from being sent. To turn off email delivery, add the following setting to config/development.rb:config.action_mailer.perform_deliveries = false\n\nThis option may be suitable if you have email previews and a solid test suite.\nChange the delivery method\nMaybe you want to have a record of the email being sent for debugging. Action Mailer can save “sent” emails as files instead of delivering them.\nTo do this, add the following setting to config/development.rb:config.action_mailer.deliver_method = :file\n\nAny emails “sent” from the application in development will be saved to tmp/mails. This saves the raw output, which might be enough for your use case.\nFor me, though, I typically want to see the email in its final, table-loaded, CSS-less, 1990s HTML email form.\nEmail interceptors\nThe final option we’ll look at is intercepting all emails sent in development and rerouting them to your email address. This only works if you have an active SMTP server or email provider configured in development mode.\nWe do this by defining an email interceptor:class DevelopmentEmailInterceptor\n def self.delivering_email(message)\n message.to = [\"jason@example.com\"]\n end\nend\n\nThe email interceptor implements the .delivering_email method. Inside the method, we’ll change the message’s recipient to our email address.\nTo wire up the interceptor, we add the following option to config/development.rb:config.action_mailer.interceptors = [\"DevelopmentEmailInterceptor\"]\n\nNow, any email sent from development will be rerouted to our email, no matter who it was initially addressed to.\nStay safe\nThese tools give us more confidence in building our applications.\nHaving Rails raise an error every time you forget to include an association may feel like a minor annoyance. But it’s less annoying than having to revisit code a few months later to fix a performance issue a preload would have avoided.\nHaving to add the boilerplate strong parameters requires may feel boring. But give me boring over the excitement of a bad actor creating a security incident for my customers.\nGo enjoy the vast magic of Rails, my friends.","aside","toc",[1525,1533,1541,1543,1551,1555,1563],{"_43":1526,"_55":56,"_1529":1532,"_1531":65},[1527],{"_43":1528,"_55":220,"_1529":1530,"_1531":227},[],"level",3,"title",2,{"_43":1534,"_55":349,"_1529":1532,"_1531":356},[1535,1537,1539],{"_43":1536,"_55":483,"_1529":1530,"_1531":490},[],{"_43":1538,"_55":530,"_1529":1530,"_1531":537},[],{"_43":1540,"_55":568,"_1529":1530,"_1531":575},[],{"_43":1542,"_55":715,"_1529":1532,"_1531":722},[],{"_43":1544,"_55":857,"_1529":1532,"_1531":864},[1545,1547,1549],{"_43":1546,"_55":895,"_1529":1530,"_1531":902},[],{"_43":1548,"_55":938,"_1529":1530,"_1531":945},[],{"_43":1550,"_55":998,"_1529":1530,"_1531":1005},[],{"_43":1552,"_55":1145,"_1529":1532,"_1531":1152},[1553],{"_43":1554,"_55":1182,"_1529":1530,"_1531":1189},[],{"_43":1556,"_55":1321,"_1529":1532,"_1531":1328},[1557,1559,1561],{"_43":1558,"_55":1360,"_1529":1530,"_1531":1367},[],{"_43":1560,"_55":1390,"_1529":1530,"_1531":1397},[],{"_43":1562,"_55":1436,"_1529":1530,"_1531":1443},[],{"_43":1564,"_55":1492,"_1529":1532,"_1531":1499},[],"Rails’ safety mechanisms","authors",[1568],{"_26":27,"_28":29,"_1569":-7},"x","categories",[1572],"engineering","excerpt","A comprehensive overview of Rails’ many safety features that can help you prevent painful mistakes.","createdAt","2022-12-12T00:43:00.000Z","meta",{"_1579":1580,"_1581":1574,"_1582":1583,"_1531":1565},"canonical","https://planetscale.com/blog/rails-safety-mechanisms","description","image","/assets/rails-safety-mechanisms-social-BWuCDhlP.jpg","pagination",{"_1586":1587,"_1588":8,"_1589":8,"_1590":1587,"_1591":1592},"page",1,"hasPrev","hasNext","totalPages","url","https://planetscale.com/blog/author/jasoncharnes","https://planetscale.com","actionData","errors"]

Posts by Jason Charnes

Rails’ safety mechanisms