The Right way to write Nest.js & Typescript clean-code - SOLID

Key Takeaways

so if you're an SGS or a typescript developer and you're not following these five solar principles then you're probably running a bad code so in this particular video we're going to see what are the five story principles that you should follow to write a cleaner and easier to maintain and easier to recode and to level up your accounting skills from a junior developer into a senior developer so we're gonna see how you can implement the five small principles to write cleaner and easier to read and easier to maintain code in typescript and in this JS so if you're coming to this video you probably already know about the other video I made about solar principles in reacts if you don't know already it's actually down below in the description go ahead and check it out to learn how to apply solar principles inside of your react applications so we're going to employ soil principles in SGS The Nest GS framework and if you're not familiar with industrious Frameworks it's a really awesome like rest graphql kind of like framework that is built on top of express.js of course on node.jsx system and it has like more than 2 million downloads per week which is super crazy and the awesome part about this one is actually uses typescript behind the scenes to handle everything so we're going to have all the features of typescript from like interfaces times classes abstract classes and so much more and I'm going to use that to apply the soil principles for writing cleaner and better code alright so the first principle for us in here is the single responsibility principle and this one actually aims to have each classroom module in the nastiest kind of application or a typescript application to have and be responsible Possible only for doing a single task or functionality so for example for us in here we have an application that has like emails orders and products so what we have in here we have inside of the orders in here inside of the controller what you can basically do is actually submit an order and actually have people to basically once they submit their order I want to send like an email like a confirmation email or order confirmation email to their email addresses saying oh thank you for ordering for us here's actually the tracking number or some information after you know submitting and confirming the order so instead of an order controller here we simply have all we just use it in here we inject in both the order service and the email service and we go in here we have this Handler which is a post Handler that handles one submit in order it takes a body so it takes the data of the order that we want to submit and so on and so forth now what we're doing in here we're basically going to do like order surveys submit order so we're just delicating that into the service because it's actually in the service that is responsible for handling orders which is called the order service and we're simply in here just like connecting it to a data base and do a bunch of stuff in here just to you know provide it with everything so we have the products in here now let's try to look exactly what's going on inside the submit order now here when we're doing just calling the Prisma order create so we create just creating the order inside of the database in here to get the Creator order here particularly there's actually a really bad approach so here we are violating the single responsibility principle and that's just because we're doing like we're using the email service which is you know another service the same service as we have in here which is the order service but what we're doing here we're trying to send an email inside of the actual submit order inside of this service now this particular method in here should do only one single thing which is submit an order like it does everything that is related to an order we're like saving it to a database and processing it to save through the database but it shouldn't actually take care of sending an email right because if somebody else tries to come in around here and actually read our code he's not going to understand exactly what we're doing here we're trying to like call the send like order email in here instead of the submit order where this physical one the order service in here should only do stuff that is related to the order and particularly this method should only submit the order and yes net just kind of like separates the concerns already by providing a controller and module and a service right over here and of course Services should only do one thing in the contrary on the other hand if you go back to the controller I actually need the right place to call and send an order email is actually inside of the controller why because the control is actually a little bit of like has a bigger scope compared to a service if I'm here forward you can just go and send an email or something after of course like you know submit an order creating to the database getting the like created order and you can use the ID and so on and so more and eventually you can just simply return a response and that's going to give the opportunity to our service in here to be reused across the application because this service can be reused basically anywhere else that's actually a service can be imported by another module that needs like the order of service and just by using the submit order it just like knows exactly that's gonna only not create it to the database but it shouldn't send an email and that's to actually follow the single responsibility principle so for example if you go to post menu and try to submit an order with lucky in a product id2 or something you click save it says oh thank you for submitting order if you get back in here exclusion here sending an email has been called and we're just simply sending an email but no no luck inside the service so but outside from the actual controller secondly we have the open close principle and that's actually one of the simplest principles but it actually has a huge value when you actually apply it so this actually tells you you want to design your code to be open for extension but it must be close for modification I know it's a little bit harder to understand that but actually using SGS because Nest GS comes out of the box with dependency injection or DOI you basically you know gonna make this principle for you a lot easier and actually in SDS always always kind of like enforces you to use open close principle behind the scenes by just enforcing using dependency injection so for the open course principle in here for example we got two modules one which is the automotive where you know the user can make an order and actually pay for the order and we have actually created another folder in here which has another module and another service and this one should take care of like the payment stuff so when the user actually you know submitted order and comes you know to the checkouts and tries to pay he can just go ahead and delegate that into the payment service and actually use it now inside of the payment service it's actually where the magic happens so there's actually the payment service and let's imagine we've got a couple of payment services right let's say we've got like a payment method you know you can use credit card or you can use PayPal or Bitcoin or maybe you want to add later on like Apple pay so much more so here we're simply doing just having a simple method we say oh process payments I'm just you know prepending in here bad because it's actually the bad approach and you can clearly see it on the top in here but here where you can give it you can give it the actual order in here and you can give it the payment method and it tries to do either a switch statement or an if else statement and it tries to do that depending on the payment method but why is this one actually bad simply because this code in here whenever you try to something like extend that code like add another let's say you want to add Apple pay for this one so for example you want to add Apple base you have to do an if statement you do payment method um equals you know Apple pay whatever and you have to do all the bunch of stuff in here so you have to actually go inside and modify the code and this code is not only for the Apple pay the code you're going to modify in here can touch pretty much all the payment methods and that kind of violates how the open close principle because it should be closed for modification but open for extension now what you should do instead to basically follow the open close principle you can go in and create another file for example payment.gateway.typescript and inside of this particular file we can just find all the gateways we have so we can have like an abstract class and here upstairs classes are very important and because you're using typescript it just makes it a lot easier so we can do a payment Gateway this one is going to have like an abstract method called process payments and here we can just basically go ahead and use the abstract class in either payment Gateway and we can just go and implement it into like different payment methods from like credit card to Paypal to bitcoin and let's say if you want to add this one we can simply just go ahead and extend the code without modifying the code so we're not touching the code we have already made but instead what we're doing just basically go ahead and creating another Gateway so we're just extending that we're implementing that payment Gateway abstract class I can hear you can just go in and do you know the logic or the code to process the payment and another method that is going to actually process the payment so you give it the order you give it the payment method and that's it you just like give it that one just go in and look into the sign of the payment gateways and actually you're going to go ahead and process the payment using the abstract class method in here we're implementing throughout all the payment gateways very easily and that's just basically to follow the open close principle so you're like extending the code but not modifying the code so the third one is liskov substitution principle so the principle basically states that oh you have to ensure that subclasses or derived classes can be substituted for their base classes without affecting the correctness of the program so for example in here for the list called principle in here let's say we've got like a pricing and orders and this pricing Morty ruined here that alluded to actually tell the pricing that the Koreans orders how it goes like depending if you have like a discounts or promotion or something like that and here we've got this pricing service simply which is a abstract class in here because we can implement it in different strategies like have different ways for example one for a promotion one for regular pricing one for like you know sales pricing and so much more and here we have this particular message called calculate price you give you the base price and you just returns for that for you so immediately you buy that you know oh this one basically returns for you like the base price immediately so this is basically not doing any modifications or whatever you give it just gives you that back and here we Define two pricing strategies so we have the regular pricing strategy and we have the sale pricing strategy so if you jump to the regular one in here we got two approaches the bad approach and the good price for the better coaching here what happened in here we're using extend instead of the Implement while we're doing that it's actually really bad approaching here because that kind of like using extend instead of implementing typescript kind of like violates how less concept intrusion principle is so simply because we're using extending here and because the pricing service has already a default method that actually does the calculation and everything typescript doesn't tell us oh you need to go ahead and Implement that and that's actually a huge mistake because the regular in here should be have it should have like a different pricing from you know the pricing service itself how you should do it instead is basically how ahead and use Implement and because when you use Implement in here you have to implement every single method because if you don't do it typescripts you guys basically just go and complain and say oh because you're implementing that you have to go ahead and Define the method so you have to do calculate price in here you have to you know basically return that or you can just do whatever you want with ads and for example for sale on here that's the same thing we can just you know the battery approaching you you never want to use extend because that's pretty bad the sale use implements and you can Implement your own kind of like calculated pricing in here you have that logic for example here you can have like a 20 discount so doing it this way we can go ahead and simply just you know follow the list cost substitution principle in here for example in here we got like the pricing service so we do private pricing services and we just put the pricing service in here and here we're injecting a particular price and service let's say right now for this particular season because we have no promotions or something I just want to go ahead and use a regular pricing strategy in here just as simple as that and I can just inject that and because this pricing service is basically the parents of this one so you can just it interchangeably use that without any issues and here we're using the calculate price in here which is the same method it can just work fine so if I go back to post button and try to give the price and you're creation here it tells us the regular price which is has no discounts or promotions five four hundred dollars but let's say we came to you know the promotion season the Black Friday or something I want to change my pricing strategy in here simply with another one so I can just easily swap it out without doing or changing any code or modifying any code so I can simply just go in and use the same pricing strategy right now I can just inject it and because you know it's part of the pricing service I have to change nothing it implements the same method I have to change nothing so that's pretty good if I save that actually have my server restarted I go back to postman in here and try to do the same thing I'll screen you have it now like a 20 discount that's the symbols that with a single line of change I can use different pricing strategies and that's what the list cost substitution principle is for the fourth principle we have the interface segregation principle the principle is simply about defining fine grade interfaces that are tailored to the specific needs of the consumers and of course it is actually going to allow you to avoid creating large interfaces with unnecessary methods that will not be used you know by you know everything but instead just splitting them into smaller interfaces so they can be reused and correctly used across you know different packages or modules so for example in here for the interface segregation principle we got like another verification folder that's all we have in here and let's say for this notification here we have a notification.interfaces.timescript so here for the bad approach is actually going and actually making an interface and actually for and actually for the interface segregation principle it's all about interfaces and how you define your interfaces correctly so here we're going to use typical interfaces in our favor so for example here for the bad approach is not like separating the concerns so you so let's say here we have like an interface a notification interface that what we want to use this for is actually like for example for sending an email which only needs like the two and subjects for example for SMS we need the phone number and message and for push notification we need like the user ID and the title so just putting them together makes it super hard to read that one of course makes like using specific values and like using interfaces very hard because you're using data that you don't need most of the time so instead of doing it this way what you should do you need to split those into a smaller kind of interfaces each does one thing and doesn't work for example email notification we only need the email properties the SMS notification we only need the SMS properties and so on and so forth and of course because we don't need all of that DNA what we have to introduce we have to introduce like the optional typescript symbol in here to make them all optional because you don't know when you have to use that or not have to use that it makes it very hard to read but instead this one it just like gives you the correct you know required and you can just use it correctly and in very very clean way and for example imagine you can use that inside of a service you want to send an email for the bad way in here you gonna basically use a notification here and a notification remember like it has pretty much everything in here it doesn't only have the properties or the fields that are only related to the email but instead it has pretty much everything shaft out into into that one but instead what you should do simply just you know use those small interface that you created and that's what interface segregation principle is all about for the fifth and the last principle we have the dependency inversion principle the principle is actually for depending on abstractions rather than concrete implementations and this just basically allows you to have a loose coupling between your components and physically AIDS easier testing and maintenance inside of your code base so for dependency inversion principle we have this like storage module in here let's imagine we have this controller where an user just basically getting sent like a get request gonna ask for file and a file name in here I'm gonna go ahead inside of our storage for example we have you know we're using let's say Amazon S3 or maybe you're using Google Cloud Storage something like that or maybe Azure whatever type of implementation you have behind the scenes so you go inside a value one you grab the file name and you go and call the storage service find Amazon S3 file and you actually give it a file name and return it and yes this is bad this violates the dependency inversion principle okay what is that so let's go inside of the storage service and go inside of the class particle in here so this is actually what we have here because this storage service should be independent from the actual concrete implementation and here the concrete implementation is actually you know finding it from Amazon S3 or maybe the other function we have in here oh find Google Cloud Storage file you know you have this very small concrete implementation inside of the service itself and this of course it just like gives you a very fine grain kind of like details of how everything should be done but instead this should be abstracted how we should go down in here and we should go in and create an abstract class so that called oh abstract class storage fetcher and this one gonna allow you to implement a specific one which called the find file you give it a fine name and you return basically the some you know the file content since that one and using this storage feature because it's an abstract class so inside of in here we can Implement different features going from the S3 fetcher or the Google Cloud Storage fetcher so here we can just simply for example for the S3 we can do a class that implements the storage feature and because you know they share this same method in here we can Implement basically the same one they have the same interface they have the same method name in here the find file they're returning the same thing and here we can just you know have whatever kind of implementation of that because this one simply is related to like the S3 and the same thing goes with the Google cloud storage unit so you can have different ones if you want to add another one you can simply go ahead and add another feature another service in here you can simply inject it you can have whatever implementation inside of it done now inside our storage module in here what we can do we can go like for example oh I'm going to use this Syntax for the providers where you can provide a class which is you know the abstract class which is our like storage feature remember this is up the abstract class we have and I can tell it to use a particular class either to use the Google Cloud Storage or the S3 storage let's say I wanted to use the S3 storage in here so I can get back and I can go to my controller so inside of a control you can use like the storage fetcher in here simply I can do the storage and I can just simply go ahead and use find file and that's it and if you ever want to swap between those instead of the module itself I can just go ahead and change between the storage or the S3 kind of implementation into the Google Cloud implementation and that's kind of like inverses the implementation or the dependencies from going to you know depending on the actual service and putting everything inside of the service extracting it into their own kind of like services and Fetchers to handle the data instead of like putting it all together in here and that's for following the dependency inversion principle all right thanks for watching hope you guys enjoyed this whole principles in this genes and typescript and catch you hopefully in the next ones