Deephan Mohan

Hi, my name is Deepan Mohan. I'm a senior software developer. I have more than nine plus years of experience. It should be actually 13, but I took some long breaks. In fact, the current session that I'm doing was after a long break. I have primarily done a lot of web development, a mix of Java and JavaScript for the most part of my career. I did my master's cut in the US in computer science. I graduated there and worked in a mix of content full-time and consulting. I had to come back here to India in an emergency, but primarily it has been web development, JTV technologies, SpinBoot, SpinMVC. When you talk about Java, it's backend, but I started as a content developer, primarily doing JavaScript with DojoJS and also Vanilla JavaScript. This is even before Angular and React. That said, I have also done Angular and React. Recent version of Angular that I did last time was Angular 6 because my previous version was in a backend road and was in Golang developer. I can also code in Python. I've done a lot of Python outside both. That said, I have exposure to MySQL, relational databases, NoSQL, like MongoDB. I used a lot of MySQL though, commercial experience, writing the relational queries. I've used ORM mappers like Avernote and so on. With JavaScript, I've done React, I've done Angular, I've done a little bit of Redux. That said, I'm trying to keep myself updated with these technologies as they work. Previous version, as I mentioned, was backend developer, but I got to work closely with another front-end developer. I don't do design. I rely on the UX developers, UI UX developers for that. That said, I can do a little bit of design using Ionic or Bootstrap. The framework standpoint, I also have other experience in different other frameworks. Underscore, handlebars, those are all very old JavaScript frameworks. I have also done Node, NPM, not so extensively. When you talk about more exposure, it's mostly about doing Angular and React from an application logic standpoint. I'm probably writing the rest layer using Swagger. Recent experience has been in Swagger. That said, I didn't do the front-end. I wrote the application logic in Golang. That said, I've used Spring Boot. We talk about other projects, different companies. Spring Boot for writing and creating the rest layer on developing the front-end Angular end-to-end on testing to deployment. Sorry, from building to deployment. I also have experience in a different series of tools. I've used mostly, that said, I've used SVN and Profos as well to talk about portion control. With SeriesDI, I've got exposure to Jenkins, AWS, CodePipeline, CodeBuild, so that I can also write big files. No problems with Linux 15 as well. It has been a full-stack journey for me so far. I've done both front-end and back-end, but you can throw me any challenge and I should be able to adapt. That said, I'm still learning.

Okay. Uh, this particular, uh, error, uh, this particular library, it's been a while since I used files. I'm just speaking from memory. Um, so some reason is that, uh, the the file for the socket that's open for this, uh, for checking if the file exists or not It's still it's still open. It's blocking. And, uh, you know, it's probably not throwing the error. It it could be throwing the error, but, uh, the files are not the sockets are not closed because it's blocking. Um, so one way to handle this is, uh, use the async, uh, library properly, uh, to make sure that, uh, the file descriptors are closed that you opened. Um, there is one thing that I can speculate. Other thing is, uh, this should be probably, you know, within a a tri class block, which is much better way of handling the errors like this. You'll get more details about what's happening, uh, because, uh, the error may not, uh, be thrown in sometimes, and it has to be handled. It has to be caught correctly properly. So, uh, if you need more context, uh, you know, try to wrap it in a tight class block, uh, so that it's handled properly. But I said, uh, my my solution would be to go for async and, uh, try to defer the, um, file descriptor, closing the file descriptor. Right? So that, uh, it is closed and it's not blocking, uh, on any errors that might happen along the way. I think that would be the way to go. Async is a good, uh, and that should be a better way to, uh, I mean, this is the NPM library, so I don't know what it's doing behind the scenes. Then mostly is sync and fetch, and, uh, trying to defer the opening and closing of file descriptors. Uh, I believe that's what EPOS is also doing. Uh, you know, recall from memory for this particular MPM module. So those are something that I can think of. Uh, try to handle that as within a proper try catch block and make sure that you have more context about what they're what the what kind of the rate is going, which it is doing. It is, uh, turning it, but, uh, I doubt if it's, uh, getting caught correctly by the enclosing scope, the object that calls the column. Um, yes. I hope I answered the question correctly. We'll see.

Okay, I cannot see the markup, I think the screen is hiding a lot and if I move, I think it could be an issue. But anyway, I'll try to answer from what I understand. I think the action is not getting dispatched properly to the, to set the state of the particular account query component. It is probably not getting tied correctly. And maybe there is a timeout feature for the clicks. Between the clicks that would be, there is a latency that's involved and the clicks are not getting registered. No, I don't think that's the problem. I think the state is not getting set incremented correctly. Set count supposed to increment count equals count plus one. That's what it's doing, then it will work. But otherwise, the set count is just assigning count plus one, you know, the initial value is zero. So, it is just assigning zero plus one, which means every time, which could either mean that the count gets reset back to zero after the component loads. After every click, it simply assigns, you know, the count value doesn't get incremented, probably. And it is simply showing what the current count plus one value is, but it's not getting assigned to the state. It's not assigning it to the state. And the state is not getting affected here. That's what I meant that the action is not dispatched correctly. So, count plus one could just mean zero plus one, you know, which is not getting assigned to count. The current value is zero, though, because that's the initial value we started out with. So, it's just printing, you know, count plus one, but count has not taken the value of one. So, if it takes the value of one, the next click could say, one plus one, which is equal to zero, two, you know. But that is not probably what's happening. The set count is not assigning count plus one to count. And I would make sure that it is doing what it's supposed to do. Set count is doing, it's assigning count plus one and assigning it back to count, which is probably what is not happening here. For some reason, the state is always zero and it is not getting incremented. What you are seeing is just zero plus one.

Um, Redux is a good option, uh, especially when the the, uh, interaction between the components in the client side is large. There's there's there's a lot of components to be designed, defined. And, uh, these components needs to share data, pass on data to different components. It's, you know, it's based it's action based, it's event based, then, uh, Redux is a good way to go about it. There are also other libraries, MobX, other flavors. For state management, Redux will be the best bet, um, because it does a good, uh, abstraction of, uh, over react for maintenance state. You can also take snapshots of the state. You can roll back to a different state or, you know, um, based on your timeline, uh, for you can also do analysis, um, about, uh, how your application behaves, uh, over various timelines. And, uh, you can roll something is not what you expected, then you can roll back the states to a consistent, you know, consistent state from previous timeline. Uh, you have that flexibility with Redux, um, with some action dispatches and so on. Um, so, yeah, the Redux would be a good choice. Um, the recent portions of Redux, I don't have much, uh, exposure, but that's why I have done Redux. Um, but, uh, yeah, there should be there should be more piece of which uh, than the previous versions. And, uh, that'll be my choice. Otherwise, you have to define your own state management type of how would you go about doing it? Um, maybe you have to write your own libraries for how you manage the state based on options. You know, how you capture it, uh, where would you store it, and uh, most importantly, how does it, uh, how do you make sure that state is shared and, uh, you know, components are inherited across which supposed to be the reusability and reduces, uh, in boilerplate. All these factors are coming to picture. And, uh, it will simply be easy to go with the industry standards like Redux, um, because it, uh, it reduces the developer time reinventing the wheel. And, uh, you can put and choose what you want. You can reduce the size of your, uh, you know, it's the library is pretty lightweight. You don't have to you can only choose the dependencies that you want, and you can reject the rest. And, uh, yeah. So Redux would be make your life, uh, more easier, especially from, you know, uh, consistency standpoint. It's easy to monitor the state and, uh, go back and, uh, you can also deprecate some features and, uh, there are a lot lot of other features that you can think of, uh, you know, suppose backward compile compatibility as well. And if you're using something like the React, it it just well with the React framework. Um, because it is written on top of React, but it means, uh, like I see on it, it's, uh, it makes things easier, but, uh, it goes well with PR. Um, the normal pressure of this impact semantics suits the React ecosystem. So, yeah, the URLs would be a good choice for the statement.

Okay, for back end services, a lot of things you can think of, what is the service? What does it handle? Like, is it a relational database that it talks to or it's no SQL database because it's more structured data, you're running more, you know, structured queries, then you may have a different flavor of how to handle concurrency. On the other hand, if it's like no SQL, no SQL, or like MongoDB supports, it's highly scalable. It supports a lot of horizontal scaling, it's more optimized for that, but not from a consistency standpoint, right? So if you're more worried about consistency, then you may have to go for relational databases, in which case, for handling concurrency, you have to introduce some messaging, messaging frameworks in the middle, on top of all the best practices that you do, right, like caching and, you know, thread pooling, so on and so forth. Right. I'll just go with, I'll, I'll go with no SQL first, if it is, if it is not, if you're not worried about consistency, because it supports horizontal scaling, on-demand scaling. And if you're using it on a, you know, a serverless environment, like AWS or GCP, you can scale based on, we have two different kinds of scaling, you can do it like predictive scaling, or you can do like reactive scaling, predictive scaling, meaning could be seasonal, the kind of load that services handling could be seasonal, not throughout the year, but on specific time of the year. In that case, you can auto scale your clusters, if it's deployed on Kubernetes, or, you know, if it is, if you're using no SQL, you can, you can horizontally scale the number of instances for no SQL, based on the demand, or if it's like reactive scaling, then the infrastructure AWS or GCP, they automatically do it for you, even Kubernetes can support that. So they automatically detect the demand and they auto scale the clusters. So this is for no SQL, if it's like, my SQL, then they're more worried about running complex queries, and, you know, handling millions of concurrent users, then you may have to go with some messaging frameworks like Kafka, or, you know, RabbitMQ, which you can set up your brokers, you can set up your topics and partitions. And these frameworks can handle millions of requests per second. And they take care of scaling as well. And then you can, you know, you can set up your monitoring and, you know, lobbying facilities with Kafka, you can use it for data management, you can also use it for queuing, you can pretty much do everything you want, you can replicate your partitions, and you can, you know, auto scale the, it also does a lot of load balancing itself. And as I said, you can have a load balancer at the top of your application, which can take care of, take the load off mostly by reducing the reverse proxy in the middle for caching frequently used data. On the other hand, in application standpoint, you make sure you do all the best practices, you can, you know, set the maximum, you can increase the thread pool, you can try optimizing it, you can use asynchronous processing to make sure that every thread handles a lot of parallel requests, every thread can do that, not simultaneously, but async, meaning it can handle many requests per second, make sure we can do that. And you know, it doesn't have to be, you follow all the best practices, you can optimize it, you can, you know, you can set up a min cache layer for frequently cached data, it takes care of, there are different retention policies, and you can do all this with Kafka as well. So you know, so from a monitoring standpoint, you can use Prometheus, Grafana, or, you know, Elasticsearch, Logstash and Kibana, look at query logs, see, you know, profile your database queries, if it's taking a long time, in RDMS, you can just explain the query and say how much time it took. But otherwise, there are a lot of profiling tools available to look at these metrics.

Okay. Uh, first thing I would do is, um, I'll try to see this change works correctly on my end by creating a separate branch, uh, a dummy branch probably, pulling this, uh, pull request, seeing if it works as I expected and or what it does what it says it does for this, uh, entire description. And I tried to understand what it's doing. If the developer is not directly involved in the feed, so when I commit and he wants me to take a look at it, and I have to make sure that the functionality is working fine. I have to see it both. And, uh, that is first thing. And, uh, after that, I look into the functionality. Uh, it's a back end change. Uh, I look at it. Uh, you know, you can go both ways about it, whichever it's precedence. Um, look at the logic of what it's doing in the back end standpoint. And, uh, make sure, you know, can probably try to even isolate it, the front end part and the back end part, uh, to make sure that, uh, you know, these, uh, these pieces are impacting correctly. Some data is getting changed or send between these pieces. Uh, make sure it is sent correctly. And there are tests written, and then I want to make sure that, uh, the tests are done properly. That is something that I would look at. That would be the last part. The first part is making sure the functionality intended is, uh, working correctly from a syntax standpoint, from a semantic standpoint. So that, uh, the application logic is intact and, uh, it is doing what it's supposed to do. Then we take a look at the tests, try to see the tests are working fine, introduce more tests. Sometimes there could be some regression issue of hiding. Try to make sure that, uh, it works from a concurrency standpoint. Address all those kind of issues, Type safety issues, threat safety issues, um, immutability, some anti patterns that can be recognized can be addressed. Security standpoint, make sure that, uh, you know, some things like, uh, the past statement, we'll just talk about that and, right, like SQL injection, CS data. All those are handled properly. Um, and, uh, then talk about, uh, you know, testing in different kinds of testing as I already mentioned, the unit testing, functional testing, integration testing, and, uh, you know, load testing if that's possible. If it's a highly scalable application, then you have to load test it, uh, see how it performs, and make sure that there is no resource leaks. These are all the factors that we have to consider. We can only go so far with some commits. You don't have to be. So so aggressive. It's early in the development. Um, if that is the case, uh, there are more things to come and make sure that you add documentation and add comments in your code so that another developer knows. We have to point out that. Um, we have to make sure that from a functionality standpoint, uh, the requirements are getting set properly, and it is getting executed properly. You know, using something like the rest. Uh, and I know it was being proved, but, uh, with the rest, uh, you can take a look at the Swaddlers team on to see, uh, the model is what is is set properly. And from back end standpoint, I should almost reflect the same functionality. It is probably the, uh, the right thing. Uh, solid principles, try and all that. My time's already up, but those are the some best practices I can think.

Okay, a lot of things you can do, first thing, if it's a front end web based application that has like a back end, which is the case in most applications, you can use a CDN, content discovery, content delivery, and like Akamai or, you know, there are other CDNs as well, where you can cache all the static data, this would significantly reduce the load time from a front end standpoint, you can fetch all the static contents from those websites, especially when there are a lot of requests and a lot of traffic. The next part is, you can use a load balancer, and for the most part the CDNs themselves are pretty powerful in doing it, otherwise you can specifically set up your own, there are a lot of load balancing options, messaging systems themselves can do this these days, they do a pretty good job of spawning new instances, when talking about Kafka, for example, spawning new instances, you know, replicating the partitions, they do a pretty good job and they do dynamically based on the threshold that we set, we can also set the retention time, caching policies, and so on and so forth. If you're talking about, you can use asynchronous processing, comes to threading, it's a Java application or whatever application, you can try using the threads, you can use a thread pool behind the scene, a lightweight thread pool, JDBC library like Hickory is a very good library, I can set the thread pools and each of these threads can act by themselves can take off a lot of concurrency, you can make sure that you write asynchronous, make it asynchronous. You can introduce streams, you can use something like WebFlux, Mono or Flux, you know, behind the scenes to make it real time. That's a significant, streams can be difficult to debug, it's very complex. But if done rightly, it can do take care of real time messaging pretty well. You can do some caching, as I already mentioned, I can introduce a reverse proxy in the middle or you can have something like memcache for Redis, where you can fetch the frequently used data. You can fetch from the cache first, if you will, it's not in the cache, then you go to the database. That said, the database themselves are industry tested for a lot of concurrency handling. They are optimized for performance, you can reduce the load, you can introduce data compaction, you can do some retail jobs, you know, it's all about, you're extracting it, you have to deserialize the data, deserialize it, you know, from back end, make sure it's compact and it's fast, use some good compression algorithm to do that. And a lot of the tools they provided out of the box in this case, so it's not a problem. That said, you have to take a look at the application logic, make sure that your algorithms, if they are used or using the optimal data structures, take a look at the queries, profile the queries, keep them, thread them, if there is some JavaScript, you know, Java, sorry. Yeah, my time is up, but Java for queries should be done.

Okay, there is a lot of decomposition best practices for moving from a monolith to micro services. First thing is a microservice is defined the why should we do what should what is the definition of microservice is supposed to handle a single responsibility only it is, you know, all tolerant, it can autoscale, it supports easy testing, it supports easy deployment, it supports easy rollback. And, you know, those are some things that are good about microservices, it manages its own state. So, the initial lightweight, you know, can handle a lot of load when done correctly. So for migrating from monolith to microservices, the best one of the best ways or the most, you know, the popular way, you know, the trend is to use a 12 factor application, whether a 12 factors contributing to how you think about structuring your architecture. So I'll, I'll give it just I'll go fast over the all the 12 factors first one is make sure that there is only one code base, you know, if you're using git, make sure all the code is just existing in that particular server. Then you take care of the dependencies and you isolate the dependencies for this application you run it, you package it, you scaffold it outside your build, it's not, it should not be part of the code base, it should be external. Then the third one is config, make sure the config is you have a dedicated config server for providing the configuration properties for your application. Fourth one is each one, each microservice should handle its own data, like instance database and stateless, it should be stateless, none of the services themselves should be storing the stateful data, but it will just go to the backend and, you know, make your two pointers building and deploying and running that process should be separate, right, for instance, the AWS has code commit and pipeline, something like that and your CTCI operations should be independent of the code base, you should talk to the code base, pull the code that way because each of these processes has inherent risks, introducing risks that might significantly affect the going to live time or the developer productivity. So these have been segregated separately. Fourth one is, the sixth one is like processes, you make sure that again, I already mentioned that a stateless process, you know, rest would be a good way to develop your applications so that none of the state is stored anywhere. And it's faster. I teach the queries request faster in a way that we understand currency better. And then you have to bind your code to specific databases, like this port only talks to Microsoft and SQL, right, MySQL, this port only is required for configuration. And you know, isolation is data porting, it's called, you know, data isolation. And the other ones, I don't have much time, but I'll try to be faster. So keeping your admin tools separate, like CloudFormation for log monitoring, logging has to be separate, then there should be a difference between dev and prod parity, both the branches should be different, and dev should have the most up-to-date code, then there should be disposability, you can use and throw, fault tolerant.

The first thing is, uh, best, uh, bet to be to use a relational database, uh, MySQL full screen. Consistency means going to a free there regardless of number of instances of number of instances of your back end, uh, service, uh, for each node, you should get the same answer. So that is consistency. Um, one way, uh, to do and for the most part, the best part is if we are using a relational database, make sure that, uh, they they are already industry tested and they do they do a better job with, uh, how to ensure consistency is handled. But that said, uh, if it is, uh, we're talking about a lot number of requests, then there has to be replication of, uh, clusters. I have to partition the instances, and we have to make sure that the data is in sync right, between the instances. Um, so in that case, uh, you know, there is either the replication themselves is not instantaneous. It is not there is a little bit of latencies, a little bit of, uh, due to the physical network ops. It cannot it cannot be instantaneous. Right? Uh, within, uh, there could there could be some delays. But during the time, during the downtime, uh, for the replication or whatever time that is for replicating your clusters, uh, you have to make sure that there is no read request coming in because we don't want the scale data to be returned from the from the node that is expecting the recent change. Uh, so we had to take some best measures like that. And, uh, we can introduce some caching layer. Uh, caches these days do a better job of syncing. Uh, they can pull the database or they can pull the application to, uh, get the recent data, keep it in sync. Can I do some retention policies? Um, if you know the kind of request that's coming in, right, like, there you can divide your notes geographically and, uh, serverless environments like GCP or AWS, uh, do this automatically based on the region. They do the replication. You can see the kind of data that's coming in, the kind of request that's coming, and you can cater to those needs. Uh, some rates may not need the recent data. In that case, you can, you know, switch it from the database. I'm sorry, from the cache. But, otherwise, if it has to go to the database, we make sure that it doesn't overload the database. We make sure the currency aspects of it is handled properly. And, uh, when it comes to read, write, uh, we make sure that it's synchronized. Um, if it supports a lot of reads more than writes, it's much better. The consistency it's it's a high important operation. Um, there should not be any issue. Right? Because, really, it's just going to return the value itself. That's there in the database. In that case, you just have to make sure that if you're using caches, some data regularly, uh, without much latency. But, otherwise, there there is lot of rights. Uh, then you make sure that there are no leads in between, especially if it's more sensitive request that has to return the recent value. You can optimize your database for read and write. You can introduce a lot of heuristics in between, uh, to, you know, to address to cater to those kinds of, uh, needs based on the requests. Um, we can do a lot of, uh, optimizations like that. My time is almost up. Uh, so, yeah, the results on this.

So maybe, um, the action type that's coming in is probably not doing the right thing. Um, so this it keeps returning the state because it keeps going to the wrong switch case. In this case, it goes to default case that it simply returns the scope. It doesn't do the push operation. It's not getting appended. So probably have to take a look at the action that's coming in. The type of action has to be add item, and, uh, it's add item, then the items gets the new item gets the action payload gets pushed to the item item setup. Otherwise, I think that's the problem here. The action type has to be add item. And, also sorry. Uh, the it's immutable. Right? So you have to create a new array. You have to push the item and set items to it. Right? So because it's const, the items that is const, And, uh, you have to make sure that every time it's appended, you appended and you you create a new array, append the payload to it. I'm sorry. Uh, take the items. Sorry. Create a new array from it. Take a copy of it. Push it to push the action failure to the copy because it's immutable. Sorry. Uh, it's mutable. Then, yeah, send it back to, uh, items. In this way, it's, uh, it's immutable again. Uh, so the scale doesn't change. It's not affected by another push item. So take a copy of items, push action load to it, then assign the copy to items object. Uh, in that way, it becomes immutable. Uh, I think that's what it should be doing instead of directly pushing the action payload to items. Uh, because it's an immutable object, uh, shouldn't be changed. A new instance has to be assigned to it, uh, if there is if there is a change. Because, uh, the state if that changes state, we have to do it the the right way to ensure immutable.

Okay. So that's a tricky question. Um, there is something called, uh, DevSecOps, security ops. So, um, she recommends that security should be taking that right from the start, hopefully, your application in every step of the process from packaging to deploying your application. Because this significant thing reduces a lot of issues in terms of addressing the problems that you might face later on after going to production or after going live with your product. Um, so, you know, DevSecOps is is getting a lot of traction of late. Uh, that's it. From a security standpoint, we have to make sure that, uh, we follow all the best practices. Um, if you're using an API, make sure the API keys are stored correctly and not shared publicly. Um, we have to make sure that, uh, if there is some services talking to each other, the handshake happens secure manner. Uh, make sure that, uh, it's your front end application. You do a SSL domain termination that all your websites endpoints with. Start with HTTPS instead of HTTP. Make sure that, uh, there is a necessary termination and takes care of the hardware use of the hardware NOS. That's the validation, then the requests are handled. Take care of course in the back end standpoint. You know, if, uh, the authorization authentication, there's some kind of, uh, authorization there at the top, like, OAuth, uh, which is pretty heavy. Uh, there are also the lightweight options, like, uh, JWT or, uh, you know, Yeah. The it's a serverless environment, uh, probably provides a lot of, uh, uh, like, high end features. Um, that's, uh, you know, more about the authorization based on the roles, uh, assigned to specific groups of people, uh, more privileges than the others. These are taken care from start of the application and follow all the best practices, uh, from the back end standpoint. If you're, uh, your IT SQL, make sure that, uh, all the security loopholes are closed. Uh, no interest to SQL injection. CSR of attacks, uh, from a load balancing standpoint, uh, make sure that, you know, DDoS, uh, all those kind of products are not will handle gracefully. And you also make sure that, uh, you know, your monitoring alerts are set up properly, uh, so that based on the logs or based on, you know, the traffic data that comes in, um, it sends prompt alert to the users to the developers and stakeholders so that they can take a look at it and find out any abnormalities, you know, in what's happening. You, uh, do endurance testing for your software to make sure that there is no resource leaks, you know, things like that. Other things, Yeah. Your API, you make sure that the application is secure behind a firewall. Uh, there's an API gateway um, that, uh, you know, uh, that is probably, it just comes with the API gateway and then goes to the back end. Uh, my time is always soft, but those are some best.

Okay, I think in the previous job, we worked with a UIUX developer and I've done with a couple of people in my other jobs as well. So they usually give the wireframes, they do it and they use tools like Figma, so what are the other tools, but yeah, there are ways to do that and the developers can take a look at it and come and post some comments on it. All these requirements are coming to them, to the UIUX developers from the stakeholders. They give us the wireframe, it's all about using the wireframe and see if it works in a front-end application. So it's all about including those assets, CSS and the gluing code will mostly be JavaScript or TypeScript, Angular. So make sure these components are, you define the components, it's fetching these wireframes and doing what it's supposed to do. From a functionality standpoint, the requirements are sent to them clearly and they do it correctly. Otherwise, it's the role of the developer to tell them what it's supposed to be doing and there are some changes that has to be done aesthetically, get the help of UIUX developers and make sure that it's taken care properly. For instance, some functionalities, some dynamic functionalities may not be given to them explicitly. For instance, developing some component, let's say a text box or a button, and it has to dynamically change color or it has to show some popover, a tip kind of markup. And we have to make sure that it's communicated to the UIUX developers so they can include it as a part of their design, make sure it's to completion. And I have to tell them that this is the requirement that I need when this action is performed and the action is, of course, is taken care of by the developer, the front-end developer. For instance, if it's a mouse move or hover over or a mouse leave event, this should happen in your asset and this action has to be taken care of by the developer. But what happens to that asset, that particular button or text box, that particular HTML element, what happens to that from a style standpoint, there are some state changes and transitions that happen behind the scenes from an HTML, CSS standpoint. I have to make sure that that is communicated to the UIUX developers so that they can include it as a part of their wireframe design. And those are some things that we have to do with them. Otherwise, they will give you the assets and you simply include that. You can probably think about optimizing the markup so that the boilerplate can make sure and that is their job, probably do that. But if it's an in-space issues that we are using, that's creating, then you have to make sure that you have to address all those issues in your front-end design to make sure that the boilerplate is reduced.