Navya Madhavi T

Well, Hi. I'm Nava Madeline. I have 7 years of experience in IT, predominantly 5 years of experience in blockchain. I started my career in 2017 as a developer at a small company, where I worked on a POC for 3 months, and then I worked as a blockchain specialist for an IoT product for around two and a half years, during which I obtained patents for the organization and successfully deployed the product to the AWS marketplace. And post that, I moved to Infosys, where I worked on 4 different projects, including starting an internal educational platform similar to Coursera, and developing the complete digital credentials process. When I left Infosys, that project was in production, and I also worked with 3 different clients. One client, based in Japan, was in the manufacturing industry and had a blockchain project based in Singapore. So, predominantly, I worked to migrate their entire network setup from Azure to AWS. Then I worked for a client called Broadridge, a financial institution, where I worked as a blockchain specialist on a live application with over 170 clients onboarded. There, my primary goal was to manage all the PI data on the blockchain. I then moved to the current organization where I'm working, and I started a product to address a couple of business problems using blockchain.

So, when the app is built, 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 in technology, there is always security, and security attacks are going, or increasing rapidly. So with the dApp, I think for the integrity of the user with Node.js and Ethereum, first, with using the defense in-depth approach, I'll ensure that all the layers of the OSI model of the specific application are secured enough. When I say all the layers of OSI, one being, like, we have to consider. Like, wherever we see the application front, I think we can do the following: if it's a web application, web application security has to be followed. If it's a mobile application, mobile application security has to be followed. And if it's a web application, I think we have a lot of OWASP top 10 tools, like OWASP. Zap is one of the tools, and Burp Suite is one of the tools where we can actually ensure that the web application or mobile application is secured enough. And then I think we have the 4 C's that is cloud, cluster, code, and container security. We have to ensure all these four C's have been secured enough. And if it is, for container security, we see, like, if it is a Docker, right, 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 are secured enough. And when it comes to the code, if it is Node.js, I think we have tools like Node.js Scan and other things to ensure that the OWASP top 10 are secured enough. And I think for Node.js, when if it is application or code-centric, we have to ensure all the API request limits are being there. All these API requests, request limits are actually configured rightly. And other things like the API key whenever an external party is trying to access our API, we should ensure that it is private enough. Probably, it is used if it is using an API gateway of AWS, then we have to ensure that the API gateway itself is belonging to a private region. So, yeah, all these we have to consider when it comes to the security of a specific app.

Well, I think for let's assume the blockchain framework I'm using is Hyperledger Fabric. And I think smart contract integration is always easy with Node.js, but the 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 gives an added advantage when it comes to the request-response model of any application. So whenever we have a request-response model, it's always better to use either Node.js or Colang. And even for 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 for Node.js, whenever we have live examples like Netflix, Hotstar, Uber, this all use Node.js as its backend 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 generally, whenever we have an OJ's backend, there will always be a controller in between as a medium, which can connect to your network and your back end or API code.

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

The current application I'm running on prod is actually made up of TypeScript due to its advantages compared to Node.js. Specifically, it's the type strict feature. And, also, we need not think of the return type, whatever we're getting. So all this will make the smart contract we're writing modular enough because, in this serverless computing, we actually deploy or expose all our services in a distributed format, which are deployed in microservices format. So I think that's where we ensure the code is modular enough. So if you take an example of Facebook. Let's say my home Facebook page is one service. Log in is one service, and view page is one service. So these three can be segregated as three different microservices, and that's where we can ensure modularity.

Well, I think here the attribute of within the user, whatever we are trying to give as an, you know, JSON object. I think the first attribute we have utilized, it has name. But we are actually again calling the user as username as one of the attribute, which is wrong because we have declared the first variable as name with a type of string. But when you are actually assigning a value, you are assigning to a different variable called username. That is 1. And also, the way we are passing the value is a little wrong here because within the JSON, right, whenever it is a TypeScript, we can actually 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, first thing, I think I don't see any try catch block in whatever the log request method we have here. And because whatever the response we get from that specific middleware or route we are getting. Based on the response, we should first have our own error handling. So there are different ways, like, if it is TypeScript or Node.js, we have a package called Winston where you can actually log all your error handling, being it try catch, being it if we have a promise, probably async await. Like, whatever here, we have used async and await, and we have used next. But I think before that, we have to log all the response, all the requests, you know, appropriately. And for the error handling part, I think we need to use try catch as a base and also use probably Winston as a package where you can log all your errors if it is the info, if it is a debug, all that.

Well, for any Node.js application, I think when we're building an application or a d app, the basic design pattern we follow is an MVC where you'll have a model, view, and controller. So using that, I think your controller would be your base, your model would be your backend, and your view would be our UI. So the technique I follow for the restful principle is that one would be the observer pattern because for Ethereum also, the design pattern is quite useful because whenever there is an asynchronous process, 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, TypeScript is not multithreaded. Right? It's a single-threaded pattern. So, with that in mind, I think whenever we have the process a and process b has to go in a 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 worker threads in Node.js where you can actually scale it up and or fork an instance of a node. And also, I think one more thing for Ethereum, I think we can have the sharding, 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 dependencies, we can have dev dependencies and normal dependencies. We'll import whatever we have and probably attach them. And also, if you're using TypeScript, you'll probably have a webpack config.js where you can have your external packages linked to it.

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