Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
I'm Jeffrey Matthias I am a developer at sang grid and this is presentation on a collection of practices about future proofing your third party services I say a collection of practices because I'm not going to tell you they're all best they're
working pretty well for us I hope you walk out of here today feeling like you've got at least one of these things that you're gonna walk out here said yeah that was it like I like that thing I'm gonna implement that hopefully there's more than
that but if we can shoot for that will be great so I work on a team whose job is to refactor legacy code we have this monolithic PHP app yes and our job is to handle our third-party interactions to go back through and refactor the way that we're interacting
with those who are pulling them out of the PHP app we're writing them in a ruby code base and since we get to start from scratch we get to look at how we want to do these things so some of the team some of the work that you're gonna see today comes
out of working with pivotal labs from about a year ago and then we've built some of our own structures on top of the concepts they gave us and have put together basically a nice path for us to continue to build out the way that we're handling third-party
services we've done this with several of our existing API implementation so far and it's worked out pretty well so the first thing is when you are going there when you're when you're going back to do this refactor or if you're building
from the first place what do you want out of your third-party implementations the first thing is you want to keep the way that they're handling their code or the way that the third party implements their ideas out of the way that you implement your ideas
there shouldn't be much correlation or crossover between that because as soon as you buy into their implementation you've lost flexibility that we as developers really like to have the next part is making your third party behavior predictable how do
we make code predictable testing and so there's a testing patterns around this that will go over but the idea ultimately is that if you can before you deploy have an idea that things are going to work well you you definitely have one right and then the
last part is making your third-party replaceable and don't get me wrong I'm perfectly aware that I work for a company that's a third party for a lot of you replaceable is still good but not just because if you want to get rid of a to replace specifically
a third party but potentially replace the API if we if a company versions up their API you like a new feature you like the way their implementation is its clean or it's better it gives you the ability to swap out that implementation or that API without
having to go back through and dig through your code or try to understand your existing implementation so from an abstract or from a bigger layer a step back you can see I'm working really hard to prove that I have a degree in art here this is about as
awesome as a drawing as you're going to get you have the billing app you've got an adapter layer and then you've got your third party system and you'll notice that I say third-party I it's got the internet or something as that dividing
line and the reason that's there is specifically because this doesn't just mean something across the internet it doesn't mean somebody else's implementation we are working in a third party or sorry in a service-oriented architecture at this
point and as an example we have a database abstraction that love it or leave it it is part of our lives for right now but the fact is a lot of us don't love it and we want to leave our code flexible enough so that when we re implement that database abstraction
we can swap in internally that database abstraction that new version of it into our code base without having it again sit there and pick apart spaghetti development so the other thing to notice is that you know our dependencies are running in one direction
here it's very rare that your third party will know about your application and you definitely want to try and avoid that situation if you can especially if there's actually options about the way that you implement things so one of the things up sorry
back on this so this adapter level the one of the most important thing to understand about it the pain adapter in this example is it is just a gem you probably knew that was coming because you know I jump to the slide early get to the point where you're
running bundle Jam adapter you're naming it it's the generator it's a standard ruby gem but you're not pushing it somewhere you're actually going to keep it in your project itself and in your gem piatt file you're going to actually
point specifically to that relative path from your rails or from your application route and name it there so fortunately one of the ways the gem files work is that you get to do that hopefully you're using this pattern other places in your code already
that you've realized that that that ability is there but in this case it's it's tantamount because this is an implement and implementation of a third party that actually does explain a lot of how you do things it's not something you want to
put out publicly and it gives you the ability also to not have to deal with having an additional repo it's still part of your existing code base but it keeps a very strong separation there now that said I just implement you know suggested doing a gem a
lot of third-party services have gems out there for implementing their work it's not to say that you can't use them you just want to wrap that execution inside of your own gem and I'll get in a little bit more about why that makes sense in a minute
so if there is a third party SDK out there leverage it please like there's no reason to reinvent the wheel especially if the SDK was written by somebody who works at the company or that third party and knows what they're doing by all means use use
that existing work so our gem is basically just a series of service level objects or service objects and they're a pretty direct pass through so they don't really know about each other and lasted unless that's absolutely needed and they speak on
one side about SendGrid logic they understand the language we're talking about on the other side their entire purpose is to translate that into the terminology of the third party system and so when we initialize our application and for us it's a it's
[ ... ]
Nota: se han omitido las otras 3.278 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.