Navya Madhavi T

Well, Hi. Uh, I'm Nava Madeline. You know, 7 years of experience in IT. Predominantly 5 years of experience in, uh, blockchain. And, uh, I have started my career in 2017, uh, as a first company in So I've started my career as a developer where I've worked for a small POC, uh, for 3 months and then uh, worked for worked as a blockchain spark, uh, for an IoT product where I've worked around two and a half years, uh, for the specific product and could get the patents for the organization or and also could deploy, uh, the product to AWS marketplace. And post that, I moved to Infosys where I've worked for 4 different projects where I've started the product, uh, which is similar to, uh, Coursera, the internal, uh, educational platform where Infosys used to have. And, uh, the complete digital credentials, uh, pro form a is what I've started there. And when I left Infosys, that was into production. And also worked for 3 different clients. One client, which was in Japan, uh, which was in the manufacturing industry, even that was a blockchain project based out of quota. So, uh, predominantly, it was to migrate their entire network setup from Azure to AWS. And then I, uh, worked for a client, uh, called Broadridge, which is a financial institution. There also I worked as a blockchain spark, uh, which was a live application where we had more than 170 clients onboarded to the application. And there, uh, it was predominantly, um, uh, you know, to have all the PI data set of the blockchain. Then I, uh, moved to the current organization where I'm working for, um, where I've started a product to address couple of business problems with blockchain.

So, well, uh, when the app is built, um, so for any application, we have to follow the defense in-depth approach when it comes to security and security design of the security framework for any application plays a vital role because always with the Virgin in technology, there is always, uh, you know, security, uh, the security attacks going, uh, or increasing rapidly. So with the dApp, I think for the integrity of, uh, the user with Node. Js and Ethereum, um, first thing, with using the difference in-depth approach, I'll ensure that all the layers of the OSI of the specific application are secured enough. When I say all the layers of OSI, one being, like, we have forces. Like, wherever we see the application front, I think we can do the if it's a web application, web application security has to be followed. And mobile application mobile application security. If it's a web application, I I think we have a lot of OWASP top 10 tools, like OWASP. Zap is one of the tool, and BurbnSut is one of the tool where we can actually, uh, ensure that, uh, the web application or mobile application is secured enough. And then I think we have 4 c's that is cloud, cluster, uh, code, and container security. We have to ensure all these four c's have been secured enough. Uh, and, like, if it is, like, for container, we see, like, if it is a docker, right, we we will try to do the image scanning. And if it is a pod cluster security, we have to ensure all the firewalls and network layers is secured enough. And when it comes to, uh, the code, if it is Node. Js, I think we have, uh, tools like Node. Js scan and other things to ensure that the top, uh, OS top 10 are secured enough. And I think for, uh, Node. Js, when if it is, like, application or code centric, we have to ensure all the API request limit is, uh, you know, being there. All this, uh, all the, uh, API request, uh, request limit is actually, uh, configured rightly. And other things like, uh, the API key whenever the external party is trying to access our a p API, we should ensure that it is private enough. Probably, it is used if it is using API gateway of AWS, then we have to ensure that the API gateway itself is, uh, belonging to a private region. So, yeah, all these we have to consider when it comes to, uh, you know, security of, uh, a specific app.

Well, I think, uh, for let's assume the blockchain, whatever framework I'm using is Hyperledger Fabric. And I think the smart contract integration is always easy with Node. Js, but major reason being Node. Js comes up with the event grouping mechanism and also the design patterns like observer pattern, singleton, all these patterns. Right? The event queuing system is what it gives an added advantage when it comes to the request, uh, request response model of any application. So whenever we have a request response model, it's always, uh, you know, it's always better we use either Node. Js or Colang. And even for lot of, uh, event queuing or synchronous or asynchronous patterns, I think it's always best to use Node. Js, especially when we have the data format or the input format in JSON. Then I think yeah. For Node. Js, uh, whenever even the, uh, live examples like Netflix, Hotstar, Uber, this all uses Node. Js as its back end because of the advantages it has.

So I think the integration layer matters as I've never worked on Polycom. I'm not really sure. But in generally, whenever we have an OJ's back end, there will be always a controller in between as a medium, which can connect to your network and your, uh, back end or API code.

Well, I think all the hashes, whatever I get, uh, you know, whenever I, uh, try to generate a nonce, I should ensure that the hash of all the required data attributes are, uh, you know, put in the right way. And, also, I think, um, it uses key 256 as an algorithm, uh, all the, uh, around Ethereum framework. So for that, uh, whenever there is a transaction, I think whenever we are trying to generate a note, we should be we should ensure that probably the hash of the last four digits can be a number like zeros as such.

Well, the current, uh, whatever the the application I'm running on prod is actually made up of the TypeScript because of its own advantages when it's compared to node space. Special specifically, it would be the type strict. Right? And, also, I think we need not, uh, really, uh, think of, uh, type or probably the return, uh, type, whatever we are getting. So all this will make, uh, whatever the smart contract we're writing modular enough because, obviously, in this, uh, serverless computing, we we actually deploy or, uh, probably expose all our, uh, services in a distributed format, which are which actually we deploy in, uh, microservices format. So I think that is where we, uh, you know, ensure that the code is modular enough. So if you take an example of Facebook. Right? Let's say my home my Facebook home page is 1 service. Log in is 1 service, and, uh, probably, view page is 1 service. So these 3 can, uh, be segregated as 3 different microservices, and that's where we can ensure modularity.

Well, uh, I think here, uh, the attribute, uh, of of within the user, uh, whatever we are trying to give as an, uh, you know, JSON object. I think, uh, the first attribute we have utilized, it has name. But we are actually again calling, uh, the user as username as one of the attribute, which is wrong because we have declared, uh, the first variable as name with a type of string. But when you are actually assigning a value, you are assigning, uh, to a different variable called username. That is 1. And, also, the way we are passing the, uh, value is a little wrong here because within the JSON, right, uh, whenever it is a TypeScript, we we can actually, uh, you know, without giving the attributes as well, you can just pass the values. And here also, we get the pass by reference issue.

Well, uh, first thing, I think I don't see any try catch block in whatever the log request method we have here. Um, and because what whatever the response we get from that specific middleware or route we are getting. Right? Based on the response, we should first, uh, have our our own error handling. So there are different ways, uh, like, if it is like TypeScript of Node. Js, we have a package called Winston where you can actually log all your, uh, you know, error, uh, error handling, being it try catch, being it if it if we have a promise, probably async await. Uh, Like, whatever here, we have used async, and we have used await, and we have used next. But I think before that, we have to log, uh, all the response, all the requests, uh, you know, appropriately. And, also, for the error handling part, I think, uh, we need to use, uh, try catch, uh, as a base and also use probably Winston, uh, as a package where you can log all your errors if it is the info, if it is a debug, all that. You know, you can use Winston package here.

Well, for any Node. Js application, I think, uh, when we're building an, uh, application or a d app, the basic, uh, design pattern what we follow is an MVC where you'll have a model view and controller. So using that, uh, I I think whenever your controller would be your base, uh, model, uh, would be your back end and view would be our UI. So the technique, uh, I think, first thing, whatever I follow for the restful principle is that, um, I think one would be the observer pattern because for the Ethereum also, right, the design pattern is quite useful because, uh, whenever there is an asynchronous process, right, like, we have, let's say, task a and task b, a process a or process b. So in these two processes, as we all are aware, the 2 TS is not multithritic. Right? It's a single threaded pattern. So, uh, with that in mind, uh, I think whenever we have the process a and process b has to go in concurrent loop, that is where this event looping mechanism has been introduced or event queuing system has been introduced by Node. Js. So using that specific principle, I think we can ensure the concurrency still can go on. And, also, I think we have the, uh, worker threads in Node. Js where you can actually scale it up and or or, you know, actually fork an instance of a node. And, also, I think one more thing for Ethereum, I think we can have the sharding, uh, being it horizontal sharding or vertical sharding for all the scaling part of it.

I think for the pattern, I don't remember the exact pattern name. But to manage the dependencies, I think we can have the dev dependencies and, uh, the normal, uh, uh, you know, dependencies. Whatever we have, we'll import that and probably attach. And, also, if you're using TypeScript, probably we'll have a webpack, uh, config.js where you can actually have your external packages as well, uh, you know, linked to it.

Well, TypeScript is all about having a strict, uh, type of whatever variables you declare, uh, whatever methods you use in the entire program. So, uh, I think TypeScript, uh, eventually is popping up more because of, uh, the simple programming, uh, modular programming techniques it has with. And as said, uh, with the introduction of the serverless computing, I think, uh, everyone should use, uh, the request response model, uh, programming language, especially whenever you have, uh, adjacent type of, uh, input data. So, yeah, TypeScript ideally ensures all your event handling in a most appropriate way.