 It's no time for you to talk about it. It's good for you. Just use your screen. Good. So hello everyone, can you hear me from the back? Backside? Hello guys. So my name is Alan and I'm going to present to you today API proxy pattern and how it makes your software API calls more reusable and mackable during testing. So how many of you guys are working on client-side applications? So how many are backend developers? Okay, that's nice. Basically, API proxy pattern is not just reusable or dedicated into Bue.js. It's also applicable if you're doing Java, if you're doing Node.js in the backend, you can still use this pattern because it's a generic design pattern but in this case, I will try to showcase how to do it in JavaScript and how it makes your code more reusable, more mackable, and more lighter in terms of bundle size. So, yeah. Let's start. So if you guys want to check out the demo application that I will share, it's available in this bit.ly link. This is the next one. So it's a slide deck link if you want to reference later. Okay, and let's start. Yeah, so the agenda of this discussion is what is this proxy design pattern, what is the problem that it solves and how to implement and improve because I will show you like the very basic usage of proxy and then I will resume with a much better form of it which is usually used for larger scale applications. And then I will showcase as well a basic good and bad testing with regards to API calls. And then we will check out as well how to introduce a proxy pattern natively in ES6. So, yeah. What is basically a proxy pattern? So how many of you are using NginX? So basically there's another concept related to NginX wherein a proxy, a reverse proxy is helping you to identify which background service are you going to hit if you try to hit a load balancer. So in code it's a little bit different because a proxy pattern enables you to centralize and encapsulate the access to a certain object so that your consumers meaning let's say you have modules in UJS so you can abstract away the mechanism that you use to retrieve data in an API. Let's say, how many of you guys coded back in 2010 like when Jake varied at Ajax rocks the world? Yeah, so if you have got, I used to work for an application that is written in 2010 that is still maintained until now. So since we use proxies back then we were able to migrate from jQuery to Angular to Vue and it's really reusable and it's quite cool. So, yeah. The basic concept surrounding it is that it's just a wrapper inside a JavaScript module so that you can reuse it between multiple components. So the common problem that you'll so this is how it looks like in drawing. I said too much but it's just something as simple as this. So the proxy stands in the middle and centralizes the access to your API. So how many of you guys had worked on a large project wherein the API calls are distributed everywhere and nobody wants to maintain them because five identical calls with several different parameter sets pass to it. This is become chaotic when you distribute your API calls. So a sample of it is something that I am bringing here. So this is the perfect example of repeat yourself. So if you see the mounted section of consumer A, I was retrieving data from localhosts, 3,000 users endpoint. So in consumer B, since another developer is working on another module, it copies it and then the party is starting. So this sample is quite simple but then when your backend developer gets started to get smarter, you'll tweak the parameter set and everything breaks down. So if the guy in charge of module B is on vacation leave, he will not update it until he's back from wherever he is. So let's go back to the slides. So if you have a proxy, this is how it basically looks like. So I know it's quite blurred here so let's just go to the code. So I am in the GitHub project that I shared earlier. So the first sample of consumer A and B were from ugly consumer project. Right now let's see how a proxy works or how it looks like. So this is a proxy sample of the version one of the application. So, yeah, we have three consumers trying to consume a centralized proxy. So if you notice what I was doing here, I now have a user's proxy and then absolutely the API call inside. So what capability does it bring to me? So first one, I'm decoupling my business layer, meaning my functional modules and the mechanism that I use to call my API, meaning your consumer modules can change without, let's say you want to migrate your application from view to react or to whatever framework is upcoming next. Since you have encapsulated the API calls inside, if you migrate your project, you can still reuse that thing. I mean the API layer, the proxy layer. So if you hard coded your Axios call inside will just be gone after migration. And it's another cost for the business. So, yeah, right now I'm using user's proxies here and it looks like this at code. So, yeah. So it's basically the counterpart to a repository pattern for those that are working on the back end. So you write a repository to access a single entity, right? So this is cool, this is nice, but it gets nasty when you're working with big projects. So what I meant by nasty is something that looks like this. You know, I had two operations here, no? First one is load all users, then the second one is get by ID. So this is okay because it's a small proxy. But then if your proxy becomes bigger, something like a God Objectlet, we all have that one entity in the application that is so complex that you need at least 20 operations to manage it. So it will start to look like this. Yeah, so your proxy can still grow to this one. So this approach can still be improved by taking a lesson from the CQRS pattern. But before we go to that I would like to share something that I see in production every day that I really hate. That's why I introduced the proxy pattern in my workplace. So this is an API call that I'm in a legacy project that we're working on. And it's literally 1300 lines. So when you try to import this thing inside your tiny module in your application it's like literally pulling a horse out of the web server because it's too big. So when you try to reshape this thing it's not going to work because a lot of internal private methods inside are coupled and married to each other already that tweaking something will break something somewhere. Because it's a centralized API call. So this is the first advantage that proxies are trying to solve. So yeah, so let's say that I have a proxy per entity let's say users. Like I have two operations to it. How can I make it even better? So you can even make that better by trying single responsibility principle approach. So when you say single responsibility you forget about your entities and start working with entity-dedicated operations. So in CQRS if you're working on big large scale applications your APIs will usually be split to a lot of small pieces. Like the rights are segregated from reads. So if you use proxy in this pattern you will be able to scale into large scale application as well. So instead of having a single users proxy I created an operation-based proxy sounds like in the golden room naming a class is that name it as a noun right? But my class right now is named as a verb starts with a verb. It looks like an action which it literally is because it's an operation that gets me the user by ID. So you get what I mean. So from like a single huge proxy I now split it into smaller pieces that look like this. So yeah. So what are the advantages of splitting to small? So if you're a web developer that will resume the work of your colleague if the file is this small I can read and understand without having so much pain in my head. Like if you have like 29 lines of code that you need to analyze it's quite easy to pick up what is it trying to do where is it getting to call? What are the parameters that I expect? And then if you want to make a change to it you're not nervous that it breaks something on the other side of the application because they share some private wiring so private methods that break something when you tweak it for one consumer. So yeah. So right now I use smaller proxies and then I also mention earlier that it makes your testing more easy. So how many of you guys are performing unit testing that performs actual API calls? Like okay so this is going to be useful at times but it's not something that is recommended because when you do unit testing you would really love to make sure that you don't rely on the internet to test the functionality of your units meaning your functions. You want to test the behavior and not the network itself. So and when you call an API let's say zero. Do you test zero in a unit test? No you don't. You want to have a behavior that you can predepine and when you use a proxy you can easily substitute it. So let's go back to the slides. Yeah so API proxies are perfect for API calls. So this is a sample of bad consumption of APIs and how it generally looks like in drawing. So yeah and this is how you use proxy in like in a better modular fashion. And then you will have your unit testing you know when you have a proxy and your consumers consuming it and it's the only operation for the API that is consumed. You can easily write a MAC object meaning a predepine behavior that is dedicated for your testing that can easily substitute your proxy meaning your consumers are now becoming more testable. So I have to prepare a sample test here that we can test so I mean I can share and just to prove to you this really works well in production I am bringing a source code here that will show you how many proxies do we have like you will see a lot of API calls in here. So yeah these are all our proxies. And proxies like I mentioned earlier don't just exist in the client side. You can write proxies if you want to let's say abstract consumption of zero API in your background API let's say you're consuming zero in the background. You can write proxy in your Node.js background application, backend application and consume zero. So meaning if you want to use a change your invoicing provider, your vendor you can easily change it without breaking your controllers. So let's go to testing So yeah so I've written two tests here so we're going to test user counter module so basically just counts the number of users in my system and it depends on load all proxy. So inside I have encapsulated access but if we want to perform an automated unit test to it I'm not supposed to call this one and I need to substitute it. So a bad test would usually look like this. So the test is actually consuming the counters without a substitute for the API call meaning if I perform the test I'm actually calling it. So why is it bad? So let's say that our counter is expecting poor when it was written let's say more users were introduced after the first initial test your test is going to break because your data is changing so it's bad to test data that is hooked to your database or your APIs. So a good test would usually look like this. It involves marking a proxy layer. So since I had written a proxy inside the user inside the user counter function I can alter the proxy function that it uses using third party library called MACRequire. So I'm using MACRequire to simulate and change the behavior of load all proxy by pre-depining a set of users that I want to count. So with the help of this I can make sure that I'm not calling any third party API so if you're working with payments, if you're working with invoicing, if you're working with authorization I had funny instance where I work on testing but I'm noob so I tried to test the authentication server and I got a block for some time because I hit the rate limit because I have 900 test cases and I tried to challenge the API module and it went really bad for me. So if you have your MAC you can now avoid performing actual API course. If you live in the Philippines connection is horrible. So we suffer from it and we need to really MAC to make sure that we can test the functions that we're trying to automate. So yeah that's all for me and I hope I had share something. So do you have question guys?