How to properly integrate with 3rd party providers
HTML-код
- Опубликовано: 3 авг 2024
- 👨💻 Learn Test-Driven Development with Laravel!
tddwithlaravel.com
Sign up to 30 Days of Laravel 👉🏻 30daysoflaravel.com
👨💻 Sign up to my newsletter and receive PHP, JS and Laravel news in a weekly-basis:
subscribe.mateusguimaraes.com
🎉 Party up:
/ mateusjatenee
/ mateusjatenee
/ mateusguimaraes
Thanks for watching! 
Наука
A very wonderful video, this is purely adapter design pattern. Nice to see more example about it
Glad you like it!
Fakes are indispensable in my opinion and I've started moving away from mocks whenever I have situations like this. Also, just watching your video made me think that a fake of an implementation is a sister of the Null Object Pattern. While used differently, they're of the same species at least. In addition to this, this is a great way to Mr. Miyagi someone into understanding the strategy pattern!
thank you!
Keep them coming! Super informative!
Thanks! Will do!
Great job, Mateus! Any plans on doing something related to Rails anytime soon? Big fan over here, keep it up!
Thanks for this! I really struggle with testing code that interacts with third party services, I'm not the best at mocking so its such a headache.
Hopefully this helps!
Nice! I really dig this way of working.
Question: Are you always using "Providers" to integrate with 3rd party solutions or do you also use "Services"? Sometimes I think it's hard to see the difference 😅
Also, would love to see a video of how to test each of the implementations. Would you in those cases use mock with http fake to fake the expected output of the api?
Both!
I try not to dig too much into nomenclature, so here’s a concrete example: you need to accept payments using different providers.
I like to approach this by having a “PaymentService”, or “PaymentGateway” interface. Similar to the videos. Then I might have a “StripeGateway”, “NmiGateway”, etc.
If the logic is simple, then maybe everything is encapsulated inside that class. More often than not, it isn’t that simple, so I end up also creating objects solely responsible for talking to these providers, and they’re not aware of the “PaymentGateway”, which is an app-level concern.
Payment Gateways take inputs that are relevant to their context, map them to something the actual integration will understand, and then parse that response.
For example… you might have a SaleRequest for NMI using Saloon that takes a certain object shape and returns a PSR-7 Response. I’d like to have that integration work by itself, and not be coupled to anything.
Then, on my Gateway, or Service, whatever you want to call it, you can take a common object between all implementations (since it follows the contract), map it to something that “SaleRequest” understands, and then map its response back to something that your app understands.
In short:
Your domain is aware of PaymentGateway
Specific payment gateways are aware of its integrations (e.g NmiGateway is aware of Nmi\SaleRequest)
Nmi\SaleRequest isn’t aware your app even exists
Your domain is not aware of Nmi or any other specific implementation
I’m on my phone and I’m not sure it made a lot of sense in writing. I can try making a diagram or some code examples later. 👍
Also - do you use a factory pattern like managers (or drivers) and could you show a bit more about that as well as a Null object pattern?
Yeah I’ll add it to the backlog 👍
I tried to listen but the cat made too much noise.
he’s noisy!