Keyur Chotaliya

Okay, so hi, this is K.U. Chaudharya from Tehrir, Ahmedabad. I work here as a senior software engineer at New York Technologies. Mostly my expertise lies in Spring and Spring Boot. I work as an enterprise Java back-end developer mostly. Other than that, I have some knowledge of Angular, basic JavaScript, ASIC call and jQuery html, css also I can handle. I have some expertise on front-end technologies but that is not my forte. I can fairly say my forte lies in Spring Boot development mostly. I have worked with many clients abroad and Indians only. I have worked with MTN and Cellulent, both are the daily communication companies and digital payment companies in South Africa. I have worked with Tech Mahindra in my earlier days. That was a project for an internal plant for mechanical parts manufacturing. At the end of the day, they wanted everything on paper so there was a website to calibrate and measure every measurement and dimensions of every part should be recorded into various kind of testing and there should be a PDF generation. So that was my first project that was in Java struts. For Cellulent and MTN, I have used Spring Boot microservices mostly along with the various CI-CD pipelines and deployment environments like Docker, Kubernetes, etc. Mostly, we were only concerned with the CI-CDs. There was a separate team for the deployment pipeline settings. But yeah, other than Kubernetes, I am also familiar with the Azure pipeline and deployment process. For SLDC, I have been working like almost five years in Spring Boot development. I have used Spring XML as well. Then I switched to Spring Boot. So far, that's been good to me. And I have also worked with technologies like Revit MQ, Kafka, and also Java socket programming. Web socket programming, sorry. Yeah, other than that, my career expectations is trying to get a remote job firstly. Since five to six years, I've been working in IT industry. To focus on my personal life, I'm looking for a remote opportunity. Yeah, other than that, if you talk about my hobby, I love to make stand-up comedy videos, and I also play piano. My current project is for a subcontractor for TRP, Tarawee E-Development Project, that is affiliated with the Adani. That is to be considered to be live every week. We provide a website for record-keeping of each of the Tarawee hut owners to be relocated soon. The full cycle from registration to a flat allotment, all the data, all the records should be kept in our project. That is also a Spring Boot microservices project. Thank you.

ok, asset properties, there is one annotation called transactional, that is required, transactional annotation make sure either the whole performance, whole operation is being performed, otherwise it is being rolled back, for any update operation, there is also one annotation called updating, sorry, modifying, that is also used to, generally that is being used with all the update queries if we are performing with the custom JPA queries, updating also ensures no other entries is being updated other than specified parameters or the unique IDs, other than that while providing asset properties, other than this two, there is no other annotation we can use, otherwise in entity manager we can always use a custom query to update, that should be fine without any annotations.

okay so real-time data processing we can achieve this with optimal use of system resource so for real-time data processing suppose there is a file being uploaded into multi-part form we can perform that operation with the either with the single file upload otherwise you can break it down into by tele chunks otherwise we can use the part info over at the part info class and send the file in parts that is also one thing while doing this operation for upload service we can apply an executor service executor service also allows it comes with what default thread setting we can use or all we can we can specify the number of threads we want to perform or we want to occupy for this particular service otherwise it comes with the check with all the available processes that is available so that is one way to optimize the real-time data processing after every file or part that is being uploaded there has to be one MD5 checksum needs to be performed that is also to ensure if file is uploaded successfully or some part of it uploaded successfully that is ultimately a goal for a progress bar that is gonna be shown on the front-end side that is the one example I worked on ultimately the answer is by implementing an executor service we can achieve the real-time data processing in a thread safe way and time-efficient way

Bridge patterns are factory design pattern, it is like bread and butter for every spring good application developer, so reusable and modular, that only factory design pattern comes in mind, other than there may be several approaches, bridge pattern is also good, but yeah mostly it is being used with the factory, based on the parameters we are passing, for the same object we can get a customized implementation or for a same repository while overridden many times into service implementations, in different versions we can specify like reusability and modularity, modularity in such a way like if service implementation is there that is performing a save operation on two tables, in second version service implementation B is there, that is performing a service operation on three tables right, so while updating service implementation one, it won't affect anything, any logic into service implementation B, so both versions can exist in a similar way in same project only without affecting each other, that's how we can define reusability, so factory design pattern can achieve this both.

ok, so in this one i think i have used hikari thread pool connection pooling is there, for hikari thread pool it does allows to create custom size of thread pool that is available for connection and simultaneous query performance without blocking most of the resources or connection since this is thread implementation for every connection pool when query operation is done that connection is being freed and again it is available for reuse in thread pool so by using hikari that is also possible rather than manually configuring spring boot connection i would recommend thread pool size and every property that is available for hikari we should use it

lazy loading and eager fetching strategies for scalable databases there is three level of normalizations the first one is to associate each of the database or each of the table with one value only each column should not contain any kind of array or multiple values that is one thing for two second level normalization that is also called 2nf that all the existing conditions that is in first level normalization for columns to get the single values to contain the single values that is there but there is one more thing called unique ID the values that is given in database that should only be accessible by unique ID and that unique ID is primary key other than the whole entry should be relying on unique ID one one unique ID that is primary key not anything else half of the data is unique for one column half of the data is using second column that is not the thing for second level normalization you can only use one primary key then there is third level normalization that is it also includes first and second level and the third level is while breaking down any of the large tables composite primary key is also to be considered that every entry is uniquely updatable or fetchable by composite primary key only for fetch type of there are JP options eager fetching set fetch type is eager or lazy we can specify as per the need for the database scale on the spring boot side whether we want to fetch all the relative data right now or we want to make it lazy loading on the run time so fetch type is the annotation we want to use for eager and lazy loading and for database there are normalizations like I explained

Exceptional height, exceptional height. As far as I know, for the cache part, other than this internal server error, there should be handling connection and socket timeout also. Suppose your microservice is not reaching even to this controller, there should be two kind of timeouts, connection timeout and socket timeout that should be handled. If connection timeout is there, it is a lack of 400 series, that is only for the calling party of this microservice, it is on the client side, so request is never gonna reach to us. To specify that, we need more than one scenarios over here, instead of general exceptions I would recommend, we should use connection and socket timeout scenarios as well. Connection timeout scenarios contain HTTP series separately and for socket timeout there is 502 and 504 that should be handled specifically, rather than creating the general scenario of internal server error. There is also user not found exception, but what if there is database error. Other than this, data access error is also there, so that also should be taken into the account in the inner cache block, that should be handled separately as well before the connection and socket timeout. Yes, that's it.

Actually, I am not very sure about why this slash is inside for every column name. That should not be the case actually. We can directly define the double quote without scap characters, even scap characters slash is wrong. So here column name we can directly assign by quoting into a double quotes without using the backslash. And generation type auto is also good but we normally use generator type identity. Auto is the auto incrementation that is fine, that is something we can work with but slash I am not sure.

The first one that I would recommend. If you want to improve the Spring Boot application startup time, use the logging level, SL4J or any kind of logs that we are creating through logs.xml to maintain the minimal impact for each kind of log because logging takes time, it takes a lot of overhead. Test load, if it is not needed for any test cases, you can avoid. Other than that, if test case boundary is being applied for a jcoco, not to be deployed if test is not covered a certain amount of code, that also can be possible by maintaining the jcoco plugin, that should also reduce the time for resource consumption. Other than that, for resource consumption, I would say, if you are using the databases, keep the database connection as a Hikari pool, so Hikari pool comes with the idle time, that also automatically disconnects the database if it is not being used after a certain amount of time. And for each query, it creates a new connection from the connection pool, so that is also beneficial for the resource management. And yeah, to log only, we can implement the actuators for the deployment time, we can use for Spring Boot startup, we can mention a logging level, that is also a Spring Boot property to keep it as as minimal as possible. And as efficient as possible, it should be logging all four kinds of logs still, but whenever it is unnecessary, that should be maintained, not to create only a class loader parts or error generation, while managing the lines of logs only, Catalina or Tomcat server can perform faster, because logs are mostly that is taking a lot of overhead. Other than that, executor service is also there to make every operation like thread management safe and implemented to consume less of the resources rather creating a separate connection that is also there, other than that, yeah, that's it.

access tier. So CSS3 features to improve responsiveness of a user. That depends on CSS3 libraries that you are importing. You can either import it separately in each of the theme page that is fine or otherwise create a central one. That should be reduce the loading time of each of the theme page if there is one central library download and then we inherit the CSS on class level. Instead of creating import URLs in every theme leaf folder, sorry, every theme leaf file, we'll be reducing, there is one, there should be one only import.html that should be creating all the import library URLs and that's it. Use the libraries on the central link that should improve the responsive interface for theme leaf.

Thank you.