Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Services, Dependencies, and
You
A guide to writing maintainable code in Go
(and other languages, really)
Sean Kelly
@Stabb...
Obligatory "Who am I" slide
● Sean Kelly (Hi!)
○ But everyone calls me Stabby
● I work for Tapjoy
○ We serve hundreds of m...
What am I here to talk about?
● Service Oriented Architecture
● Defining Dependencies
● Separation of Concerns
● Practical...
Service Oriented Architecture
You mean like, microservices and stuff?
(Spoiler Alert: Not really)
Service Oriented Architecture
● Many ways to define and apply this
● Internally architecting your application for SOA is a...
Dependencies
Ugh, is he gonna tell us to use some interface{} abusing DI
framework?
(Spoiler Alert: Nah)
Dependencies
● External resources you rely upon to execute code
● Common examples:
○ MySQL
○ Memcached
○ Riak
● Less Commo...
Separation of Concerns
Is that like when your code isn't a jumbled mess?
(Spoiler Alert: Yes!)
Separation of Concerns
● Modules of code should have 1 purpose
● Don't lump things together out of convenience
● Each dist...
Testing
Ugh, Booooriiiing
(I know, but these designs will make testing easier)
Testing
● Service Objects with their dependencies declared in their New method: 80% of
the way there
● The other 20%: Inte...
Wrapping Up
Wait, already?
(The rest of the talk is some code examples)
Services, Dependencies, and You
● Primary focus is to keep code "clean" and DRY
● Each service does one thing, and does it...
Thanks!
Services, Dependencies, and
You
A guide to writing maintainable code in Go
(and other languages, really)
Sean Kell...
Upcoming SlideShare
Loading in …5
×

Services, dependencies, and you

623 views

Published on

On Slide 13, the "Code Examples" are here:

https://github.com/StabbyCutyou/blunderbuss

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Services, dependencies, and you

  1. 1. Services, Dependencies, and You A guide to writing maintainable code in Go (and other languages, really) Sean Kelly @StabbyCutyou
  2. 2. Obligatory "Who am I" slide ● Sean Kelly (Hi!) ○ But everyone calls me Stabby ● I work for Tapjoy ○ We serve hundreds of millions of ads a day on a global scale ● I have a new puppy and a new kitty ○ Some of these slides might accidentally veer into tips on Crate Training ● I maintain a bunch of open source libraries ○ That literally nobody uses ○ It's actually kind of fun, since I can break things with less repurcussions
  3. 3. What am I here to talk about? ● Service Oriented Architecture ● Defining Dependencies ● Separation of Concerns ● Practical example of applying the above in a Go webservice
  4. 4. Service Oriented Architecture You mean like, microservices and stuff? (Spoiler Alert: Not really)
  5. 5. Service Oriented Architecture ● Many ways to define and apply this ● Internally architecting your application for SOA is a great pattern for maintaining application code ● Keep crucial business logic out of Models and Controllers ○ Helpers like combining First + Last into FullName can live on a Model ○ Try to avoid ivory-towering yourself into code no one wants to maintain ● Centralize it in reusable Service objects ● These objects define domain boundaries in your systems ● These objects also define dependency maps between the parts of your systems ● Eventually, if you do break your app up into microservices, internal SOA has already got your code in a "ready to extract" state
  6. 6. Dependencies Ugh, is he gonna tell us to use some interface{} abusing DI framework? (Spoiler Alert: Nah)
  7. 7. Dependencies ● External resources you rely upon to execute code ● Common examples: ○ MySQL ○ Memcached ○ Riak ● Less Common examples: ○ Configuration data ○ Other code modules ● "Hmm, I need access to X here…" ○ That is probably a dependency ● Passing dependencies down via a constructor makes for more testable, reliable code. ● Avoid "new-ing up" a dependency unless it's in your main() and handed to others
  8. 8. Separation of Concerns Is that like when your code isn't a jumbled mess? (Spoiler Alert: Yes!)
  9. 9. Separation of Concerns ● Modules of code should have 1 purpose ● Don't lump things together out of convenience ● Each distinct piece of your domain should get it's own Service object ● You can compose Service objects to create "Higher Order" Services ○ If Service A needs Service B, but Service B needs Service A… ○ You need Service C, composed of A and B ● So, if you had some basic Services like these: ○ UserService ○ ErrorService ○ ThirdPartyMailerService ● You might compose some Services like these: ○ AccountManagementService(UserService, ThirdPartyMailerService) ○ AlertingService(AccountService, ErrorService, ThirdPartyMailerService)
  10. 10. Testing Ugh, Booooriiiing (I know, but these designs will make testing easier)
  11. 11. Testing ● Service Objects with their dependencies declared in their New method: 80% of the way there ● The other 20%: Interfaces! ● If instead of this… ○ NewAlertingService(*AccountService, *ErrorService, *SomeEmailProvider) *AlertingService ● You did this… ○ NewAlertingService(IAccountService, IErrorService, IEmailService) IAlerteringService ● You could replace any of the critical dependencies in a unit test with mocks or no- op implementations ● You can now use tools like `gomock` to generate test implementations for you ○ Or, just do it yourself if your services are small / have specialized testing needs ● Conversely, you could mock out the dependencies of those Services ○ But usually, whole-mocking is easier and more straightforward
  12. 12. Wrapping Up Wait, already? (The rest of the talk is some code examples)
  13. 13. Services, Dependencies, and You ● Primary focus is to keep code "clean" and DRY ● Each service does one thing, and does it well ● They define dependencies in the constructor / New method ● Create "Higher Order" Services by combining existing Services ● More easily testable with both unit and integration tests ○ Especially if you use Interfaces ● Lays the groundwork for extraction into microservices, should you choose to ○ If the code is cleanly separated, and has well defined dependencies, it's more straightforward to port ● And Now… Sample code!
  14. 14. Thanks! Services, Dependencies, and You A guide to writing maintainable code in Go (and other languages, really) Sean Kelly @StabbyCutyou

×