What's wrong with ActiveRecord?

Transcript

1. What's wrong with the Rails Way
2. Active Record
3. Agenda Design • Validations • Callbacks • Concerns Performance • Selects • Updates • Inserts • Deletes
4. Validations
5. A simple task
6. A much simpler solution
7. A manager’s request: introducing A/B testing
8. Wait, Rails has conditional validations
9. Another business requirements
10. That’s all? I already finished. I wanna a real task
12. Another business request
13. Attempt...
14. But....
15. Rails way(a.k.a pain in the ass) solutions • adding a new flag attribute • save(validate: false) • update_column • connection.execute(raw_sql)
16. What should we do with that?
17. SOLID
18. Creating a separate validation class for each input dataset is the clue
19. The right approach using ActiveModel::Validations
20. Well-known solutions • Form objects - https://thoughtbot.com/blog/activemodel-form-objects • ActiveModel-based validations • Dry-validation https://dry-rb.org/gems/dry-validation/1.5/ https://www.youtube.com/watch?v=nOUPIa7tWpA More about each concept here - https://gist.github.com/woarewe/1c4895378fac77e6a39e4a8fc139ecc9#valida tors
21. Callbacks
22. Explicit is always better than implicit
23. Common uses cases • Post-processing: notifications, enquing jobs, No-SQL and MQ sync(elasticsearch, RabbitMQ, Kafka) • Pre-processing: deserialize data from forms, coerce types • Trigger other triggers - touch, touch, touch
24. What if we need to skip some callback?
26. Why is it the worst practice? • Unobvious and implicit behavior • Forces you to use several interfaces to communicate with DB, basically, if you see a code with update_column you can’t understand if it’s for skipping callbacks or optimization, or etc. • Production scripts are super dangerous • Should I mention testing there? • The concurrency control(nested transactions, locks) is getting super hard to maintain
27. Just create one more step/function/method in our service objects
28. User.create!(params) vs UserCreatorWithEmails.new.call(params)
30. Performance
32. Data setup • There are 100 users • Every user has 10 posts • Every post has 20 comments • Every comment has 10 reactions
33. Selects
35. Why does it happen?
36. Rails runs your queries only on demand
37. How to prevent that?
38. Rails 6.1 introduces strict_loading
39. Better code reviews
40. Gem bullet
41. Have a look at rom-rb and a repository pattern
42. Deleting
43. #delete vs #destroy
44. #delete
45. #destroy
46. What might go wrong?
47. Timeouts...
53. Сколько там говоришь?
54. Inserts
56. Our task is to save a bunch of data. For instance: import CSV, API sync or consuming MQ
57. Data setup
58. Possible solutions
59. Rails developers’ choice
60. Profitero engineers’ choice
61. Rails 6 insert_all
62. Gem activerecord-import
63. Benchmarks
65. Updates and inserts
66. Imagine, than you sync data and a part of it is already persisted and a part is new
67. A typical solution
68. - What about timeouts? - I just run it in background
70. Common raw SQL won’t help! You are able to set the same value for several rows but what to do if you need to set unique value for every row?
71. The answer is UPSERT
72. UPDATE + INSERT = UPSERT
73. Basically
74. Let’s modify well-know solution
75. Raw SQL, again? Oh, I’m not a JAVA developer
77. Benchmarks
79. Summary time
81. YOUR TEAM LEADER YOU, ENJOYING HOW AMAZING RAILS IS
82. Summary • N+1: it’s not only about selects • The rails-way is a bullshit • Models without validations and callbacks • Preload data you need • Easy is not simple • Understanding tools that you use gives a huge advantage
83. Thank you!