SAISH NAIK

Yeah. Hi. My name is, hi, my name is Saish Knight, and I'm a senior software developer. I have, uh, 5 years experience sorry, 6 years experience in Golang. And I also worked with Node. Js, which I have around 6 years experience in that as well. I'm currently working in a telecom based company. So I worked there on microservices, Golang, Node. Js, and, uh, like, AWS. We use AWS word cloud. Then we have, like, Kubernetes for, uh, container orchestration. Uh, in total, I have an experience of around 9 years.

So most of most of the time for solid principles, if I'm using, uh, Go lang, I basically try to use interfaces, then interfaces are basic thing for solid principles. Single responsibility as in I would only use a function to do one thing and not more than that. Correct? And then if we are talking about objects, uh, modification, that is if you do, uh, if you do want to keep your object open for your the object for to change the old functions and only and only you keep it open for modifications. So that for that, I actually use an interface. Okay? So by sending in the interface type, you can, uh, actually achieve that. Okay? So that is, uh, o's the o in solid sense for open close principle that is for, uh, open, uh, for what you say modification. Okay. Open for modification, but, like, close, uh, close for modification to the original code. Okay? So open for new changes, but, uh, close to change the existing code. So that can be achieved by using interfaces again. Okay? So I would like to give an example, but let me go on to the Lishkoff substitution principle. This cost substitution principle basically says is says that it it should be easy to substitute values. Okay? Again, here, we'll be using, uh, what you call as interfaces. So for this one as well, we will be using an interface. And let's just say if we have something like, um, MySQL or Mongo. Okay? So if if I'm using MySQL at the moment, I won't be passing the MySQL struct, rather I'll be using the interface. Okay. So based on that, we can, uh, follow the list of it. Now in the future, if I want to change it to Mongo, I will I just pass in the interface. So my my still in Mongo will follow a certain interface. Let's just say a DB interface. I'll be passing it to that. Okay? Uh, then interface segregation. That is the eye of it. That means we will be creating, uh, how do you say, big interfaces. We'll be, uh, dividing it into small and smaller interfaces. Okay. So what happens is let's just see if I keep a big interface. Okay? Uh, I will any struct which has to do something okay, which has to, like, suppose it, uh, we are talking about, uh, some sort of job or some sort of action that it has to perform, It has to do all the actions of a big interface. Okay. Sometimes it that strap might not have to you know, you might just have to return nil or something like that or just write some dummy code. Okay? So if we do want to avoid that, we would have to do an interface aggregation wherein we'll be separating our data. Okay? Now, uh, let's talk about, uh, d, that is the dependency inversion. So we won't be, uh, depending on the direct implementation of the code. We'll be dialed actually depending upon the interface. By doing so, it's much easier to, you know, replace any sort of, uh, object. Can easily let's just say we are expecting, like, a MySQL. We can just put in that. If you want to pass a Mongo, we can put in the Mongo. We can make the Mongo follow the index.

Or if we are talking about AWS deployment, we will be creating, uh, what do you call as a private networks everywhere. So, like, if I'm deploying, suppose, uh, microservice architecture, in that case, I will be pushing all of this into one secure network. Okay? So you can create your own VPN or a virtual also a virtual private cloud, not VPN, but rather VPC. And when you do this, only then these resources can and you'll put all of your resources under this one VPC. So by doing this okay, by doing this, by creating resources under so whenever you create the infrastructure, right, in a if you're using some, like, data form or something like that, you can create your own VPC. Okay? And then all of the other clouds, right, like, all of the other, um, servers of yours will be using that VPC. So and how do, like, how do we secure that is basically, uh, you will be allowing restricted access to them. Okay? You won't be allowing any other server or any public to public to explore, uh, to use it. So that's how I would do it. Other than that, if we are looking at in terms of, uh, credentials, okay, so we can have, uh, in AWS deployment, we can use secrets as well as, like, if you're using something like a Travis CI for doing an AWS requirement. You can save your secrets in that Travis CI file. So which will not be exposed to anyone. And that's and to securely, like, log in to using a resource, suppose you have, like, a database or suppose you have, like, a file store. So based on both of these, you'll be, uh, uh, you'll be using that and, uh, to you know, to do all of this stuff can be done using that. That is one way. Also, you can, like, um, in terms of deployment, that's how I would go with it. Like, I would be saving the secrets that way. Also, if you are looking in terms of Kubernetes or other deployments, okay, so you can, uh, then save your secrets in there. But, like, uh, in case of AWS, that's how I would go.

So dependency management, I mostly use Go, uh, mod. Okay. Now prior to this, we usually use dev, but now it's all about go mod. And to avoid see, how do we avoid a version conflict is, like, suppose let's just say, you there are 2 ways of going about it. One way is to do vendor. Okay? So if you don't want your version to be affected so, basically, what you would do is, uh, you would, uh, you would say you would say go mod a vendor and then create a vendor folder and then just push over that vendor folder. So what will happen is your dependency versions won't change. Okay? Now let's just say you're talking about dependency versions in terms of version conflicts. Okay? So how would you avoid something like a version config? Let us let's just say if some developer has one more version and you have another version. Right? So that's if in order to, you know, uh, use that you'd be, uh, you would use Go mod. Okay? Again, then you would use Go mod tidy every time. So and then you would see, okay, whether all of the resources are working correctly or not. Okay? So let's say you have, like, some sort of a GIN, supposed GIN we are using, and then you have the dependency map. You have the version product. So I would say go more. I need this version. So I would say go more. Download this version. This will say, okay. I need a version greater than or equal to so and so. Okay? If if when I say this, then there will be hardly be any version of this. And to yeah. So we're in motion problem maintaining a clean environment. So, yeah, one way is, like, to do the use the vendor or the other way, our way our way is you, uh, basically, uh, put your home mod into your, um, my into your VCS. Okay? And then we can handle this kind of, how do you say, situation?

So when we talk about go line, if I'm talking in terms of more microservice architecture, first of all, are you would you use distributed tracing with all of the errors? Okay? Like, uh, and when I'm, uh, like, um, in, like, let's just say, if I have an error, I will be grabbing that error. Let's just say I get an error from the MySQL DB, and now that will be propagated to the service that will be propagated to the controller. So what I'll do is it should directly just throwing in any error. Okay. Saying, like, okay. The controller didn't work, but service did not. I would rather grab the error. Okay. So by grabbing the error, I will get exactly where the error failed. Okay? So that's one way of, like, you'll know how it is. Now in terms of, uh, maintainable, as you know, this is, like, this would be much easier maintain easier to be maintained. Okay? Uh, with respect to robust, I don't really, uh, have a I don't think there would be any issue in maintaining or like this not being robust. Okay? With respect to also the errors, right, like, now because we have a microservice which is showing an error. So how do I know which microservice actually throw that error? So I will be using elastic search logging. Okay? So I'll be logging the error. And the other part is I would be using distributed tracing. So distributed tracing will help me in identifying where actually the error appeared using the trace ID. Okay? So that's one way of going about it. And, uh, yeah. And other ways, if we are talking about robust, I'm thinking it is, like, more about how can we recover from the virus. So in this case, there is something called as recover. Uh, so what we can do basically is we can say instead of putting it into the panic, we okay. Let's just say we, are likely have an important piece of code. Like, if it fails or if something happens, it is likely to panic. Although we should never try to avoid panic because if there is a panic, that means there's something wrong with your phone. But if we want to build a system like that, then we have to put it into recover. But just not just putting it into recover, but logging the actual error. So and also raising maybe, uh, how to say, a Slack alert or an off Genie alert, something like that.

Oh, okay. There are a lot of functions to do with this. A lot of libraries, okay, to implement rate limiting. So you can, um, use those libraries basically to, uh, to, uh, prevent the abuse on that. Also, one thing you can do is instead of actually these things hitting your server, you could do it at the API gateway level if that is possible because most of the abuse will come from the services which are exposed to the public. Okay? So one way of doing that rate limiting is using some sort of, um, Redis. You could have, like, a Redis store which will keep the account and then prevent it from doing it, or you can keep a load balance in front of it and then say, okay. This is the amount of load it can handle. It shouldn't say no. But, uh, in case of Golang, there are a lot of things to prevent and abuse for, uh, like you could say, the maximum buffer style or the maximum body size should be so much. Uh, like, uh, too many, uh, or same client connections or same client IP you can restrict. Okay? So there are a lot of ways in doing this, but I would, like, rather go if I'm going for rate limiting. Right? I would be doing it based on, uh, IP because IP, if there is 1 if you're someone is firing from one server itself, we can use the IP. In that case, you can use also, like, if you could get, uh, the user agent. Okay? Like, sometimes what can happen is the IPs can be the same, but the user agent can be different. So again, because to separate those 2 monitors so that you you can use a browser fingerprint basically to identify this kind of stuff. Um, more for rate limiting. Other than that, like, I if there are already, I think, 3rd party implementations, okay, which we can use, uh, to, um, block any of these. Okay. Block the IPs, block spam, block. You can also use a set of, like, how to say, commonly used VPNs, which you get from IP 2 location. Okay. Basically, those can also be used to fix this.

Okay. Yeah. So, basically, what is happening is we have created a main function, and the first part of it is, you are sending to a channel. Okay. There is no receiver for the channel, and you are trying to send to a channel. Now this channel is called as an unbuffered channel. That means that, basically, the for this channel, if you send or receive, okay, like, in this case, since you're sending, okay, and there is no receiver, it will block, okay, until a receiver is ready. But since you already sent to it and there is no, uh, goroutine running, which can unblock it. Okay? So I have sent with the function, but there is no go routine which will receive this because you have not found a go routine. That's why it will definitely result in a deadlock. Okay. So to fix this, okay, what you can do is the go routine code which is there. After the send, you can push it forward. Okay. And then what you can do is this will, like, with the time not sleep. Okay? And then what you can do is this will, like, with the time not sleep. Okay? It will, uh, then print it correct.

First thing I would like to say with regards to this error, right, you don't know from which and what function it came from. Okay? So, basically, let's just say in the code, you are looking at this code. Right? Supposed to return the my instructor there, but you don't know from where it came from. Okay? So I would then like to add, like, certain functions. Okay? Like, you could wrap it with, uh, saying, okay. This came from fetch and pass. Okay? Because as you pass it, uh, like, to the upstream or the upper code, it will no one will know from where this function came from. Other than that, if resource is not equal to nil, Also, I would, like, it will be better to do like, if resource is not equal to null like, even if error is not equal to null, if there is some sort of body, then we can try to close it. And then if error is not equal to nil, return nil and error. So here in that error where we are returning, we can use error.wrap. So not errors or web. You can use percentage w and then get this back. Okay. So to grab the error. Other than that okay. So here also, now this will give you an error saying, uh, cannot convert into JSON or some sort if there is some sort of error with decoding it. Okay? So if there is some sort of error with decoding and then you can do, uh, then you can, uh, throw a better error because this error is not clear. Okay? Here, that error won't actually specify what went wrong, like, in a better way. Like, instead of, uh, throwing a MagalDA code, which will be, you know, difficult to read, that will make it better.

Okay. Okay. So we are looking to handle a massive influx of API calls. Okay. By default, Go has its own Go routines. Okay? We'll have its own Go routines, and it will do the context switching on its own. But if we want to manage and let's just say we want to do some sort of rate limiting, so what do we do is basically we can put a queue in front of the request. So this this is something called as an internal queue. So what happens? Let's just say we receive an API request. We don't directly you know, if it's like, there will be certain API request, which we don't want to directly give an API response to. Okay? Uh, that is we don't want, um, a request response warning. So it's just, like, it could be, like, a post call or something like that. So in that case, what we'll do is we'll take the request. Okay? We'll use it into the queue. We'll put it into the queue. Okay? And then we will slowly pop out from the queue. Queue. So the first request as it, uh, it will be, uh, enqueued. Okay? And then it will be d q. So as as in a queue, the first one the first request request which first option will get the priority. So what it will do, it will take the request. Now let's just say we have some sort of when we say context switching, I'm guessing this is, like, more of an API code. Okay. So this will be handled by Go. And what we'll try to do is we'll say, okay. Let us do its job, and we'll then try to get the next request. Okay. So let's just say that we have 2 requests. The first request we're handling, and it has to make some sort of other call. So in that case, what we can try to do is we can have some sort of, uh, maybe say a lock, a mutex lock basically and say, okay, now we can handle these many requests. This request is gone and doing something else. Now we say, okay, let's release the law and let other request come into that. Okay. So what it will do is when it makes another call, the first request which was selected might make another call. At that point, instead of just waiting here, we could do normal that. There are other ways of also doing it. It's something called as, um, what do you say, pipelines. Okay? So, basically, what we can do so one thing is you can put a log and then tell the queue, then you can fetch another use another go routine and fetch another thing from the queue. Okay? So that is one way of doing it. That's how you control the context switching. The other way of doing something like this is, let's just say, uh, we are we have a certain limit. Okay. If we have a certain limit, we can have, like, a buffer channel. Okay. And say, okay. These many requests should be there. After that, we will wait for that channel to, uh, you know, be full. If the channel is full, that means, okay. Now we cannot handle any more request. Okay? Once the channel is released, then you will again, uh, like, pass it through that way. Tell you. So we can have, like, a follow-up wherein we are passing all of the request. Okay? Let's just say we have only, like, a 10, Okay. Ten request only which we can handle. At that point of time, we'll say, okay. Only 10 request from the queue will be done. The later one, the next one, which will be there, we will try to send on the channel, but it will be blocked because it is a buffer chain, something like that.

Experience in integrating whole lag applications with external services using the AWS SDK. Okay. I have actually used, like, to, you know, sync up with other parties, like, uh, how to sync. Like, basically, if you are not using your own system and you have, like, someone's SDK where they have given you, like, an API key to work with. I've used it in one of those projects, but it was, um, it was not a big project. It was, like, uh, I think, uh, 2 or 3 months, something like that. So it's not a big project wherein wherein we'll be using the Go app lang application, making the call using the SDK. Okay? And then, um, yeah, it's not I don't have so much experience in that.

So in Kubernetes, we can use the Kubernetes Autoscaler. Okay? So in that case, what we are trying to achieve is like we have let's just say we have black market, uh, Black Friday sales basically. In that case, we want our system to handle that big traffic. So by using the Kubernetes auto scaler, which will automatically scale it based on what what about metrics that you want to use. Suppose you want to use, like, CPU, suppose you want to use the average load, something like that. So based on that, you would automatically do it. So it doesn't have much to do with in terms of Golang services. Okay? But it's got to do with how we would handle it in, like, Kubernetes. Okay? So in Kubernetes, you can have that. And ideally, um, yeah, you can you can use that kind of a scenario wherein we could, like, auto scale based on the loan. Okay. And I think that would, you know, actually be the better solution. And with this regards to, like, variable loads, right, like, this is this is something which is, like, going to happen, like, in case of ecommerce business, we are likely going to have it, so we can use that. Other than that, if we don't want to handle the load, like, or we want to say, okay, after certain that we don't want, we can have some sort of system for that as well, like a rate limiting. Okay? So we can use rate limiting as well.