FUNCTIONAL PROGRAMMING SERVICES
•
8 likes•3,703 views
Tired of writing messy messy "if" statements for all your exception handling? Learn how to take full advantage of functional programming theory, without the theory, Ruby-style! https://github.com/mindeavor/solid_use_case
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (15)
Similar to FUNCTIONAL PROGRAMMING SERVICES
Similar to FUNCTIONAL PROGRAMMING SERVICES (20)
Recently uploaded
Recently uploaded (20)
FUNCTIONAL PROGRAMMING SERVICES
- 2. Overview • What is a Service Layer? • Railway Oriented Programming • Creating Beautifully Composable Services
- 5. A Service is an object that represents a process.
- 6. A process is something you do. • Typically initiated by the user • Usually implemented as a dedicated class • Named with verbs, not nouns • Examples: SignupUser, PurchaseItem, etc. SERVICES
- 8. A Service in Rails SERVICES CODEEXAMPLE A Service Usage in Controller
- 9. [Naive] Validations CODEEXAMPLE A Service Usage in Controller SERVICES
- 10. Why a Service useful? • It encapsulates domain logic • It thins out your models & controllers • It ties together cross-cutting concerns • It makes your Rails app easier to test. SERVICES
- 11. A service layer is about clear separation. • Rails depends on the service layer • The service layer knows nothing about Rails (routes, controllers, & views) • Other things could depend on the service layer (REST API, web sockets, rake tasks, etc.) • ActiveRecord is unavoidable, however. SERVICES
- 12. SERVICES
- 13. Quick Recap • A service is an object that represents a process • Services encapsulate domain logic for specific processes • No functional programming (yet). SERVICES
- 15. Services: Another Perspective A service is a sequence of steps • They often involve a lot of setup • Authentication, authorization, validation, etc. Any one of these steps could fail • How to handle failure?? RAILWAY
- 17. Can we do be er? RAILWAY What if each step was an independent method? How would each step communicate?
- 18. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming RAILWAY The “Switch” Input→ Success! Failure. fetch_item DIAGRAM
- 21. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming RAILWAY Our Target Flow onsuccess Success! Failure. Input→ fetch_item validate onfailure
- 22. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming RAILWAY Our Target Flow Success! Failure. Input→ create_ordervalidatefetch_item
- 23. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming RAILWAY Our Target Flow Success! Failure. Input→ create_ordervalidatefetch_item IT’DBECOOLIFWECOULDCONNECTTHESETOGETHER
- 28. RAILWAY Answer:
- 33. There’s a gem for that! Doesn’t matter. RAILWAY github.com/mindeavor/solid_use_case
- 34. There’s a gem for that! Don’t worry.
- 37. Quick Recap • Split steps into methods • Return a success or failure in each one • Elegant (with gem) error handling! • Steps can be tested independently RAILWAY
- 40. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming COMPOSE Input→ Success! Failure create_ordervalidatefetch_item What if we treat it like a single thing…
- 41. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming COMPOSE Input→ Success! FailurePurchaseItem What if we treat it like a single thing…
- 42. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming COMPOSE Input→ PurchaseItem Success! Failure What if we treat it like a single thing…
- 43. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming COMPOSE …and then connect it to other things?? Input→ PurchaseItem Success! Failure
- 44. Source: http://www.slideshare.net/ScottWlaschin/railway-oriented-programming COMPOSE Input→ PurchaseItem EmailReceipt Success! Failure …and then connect it to other things??
- 48. Recap • We can compose services like we can steps (in fact we can compose anything that returns our success or failure) • Functional programming rocks! COMPOSE
- 49. Conclusion • Service layers are great for apps more complex than CRUD • Railway oriented programming is great for seamless error handling • Functional programming gives us composable services!
- 50. In the end, don’t take my word for it.
- 51. TRY ITYOURSELF!
- 53. Further Reading • http://martinfowler.com/eaaCatalog/serviceLayer.html • https://gist.github.com/blaix/5764401 • http://fsharpforfunandprofit.com/posts/recipe-part2/ • The gem: https://github.com/mindeavor/solid_use_case