 We are related to the rocks that happened, so if there is a question that you have to say directly to one particular student and ask them or if it is a general question, either of them can ask. So just keep it sort of in the next with one of the first three. Anyone can start. Raise your hand. Who is this? Who is going to be the first one? The first person? So we are actually building a new project which is quite complex. And the packing structure is quite different as we restate it with microservices. And on the UI side, we are working on a step, like whether to use Redux or we are exploring middleware or the Apollo or the UDA model. So we are quite interested on the packing. It is basically microservices which doesn't have a wrap cure wrapper. But my question is that should we use a wrap cure client here on the client side? Is it possible to use the... So we actually used the wrap cure to the client side. So I thought this is quite closer to what we're doing. In our activities plan, for example, in our company, we can enterprise APAs. So it's quite a huge fund and there will be APIs kind of in some microservices system. So there are separate teams managing APAs. And so we have two options. So you say either people, the imperative rate or the declarative rate. So this is actually the kind of shift that the programming world is actually going towards today. As we've also mentioned today in the morning, we move from imperative rate to the declarative rate and we move from a jQuery to reaction. Similarly, on the client side, like API side also, Redux is more on the declarative part where in whatever time period you think I just started talking about, you always say, okay, now do this call to API, get water response and give back the data. Do this kind of massaging on the data and then return. The things that you have to specifically say. And on popular graph theory, it is more declarative. You just say that before this component, this is the query. I don't really care about how the data comes and it should just come and show up. That is, I think that is kind of the one which is going forward to use it because why do you want to handle complexity? A declarative way is much better to go. The way we are going to do graph theory is we get the enterprise API as it's doing today. We just created a separate graph theory server which is kind of standing in front of my client and API. And it is kind of a facade to all the API. So I just make a call that, okay, I don't do this, this is details. It is my graph theory's concern to say that to get these details, probably I have to get like two, three different API data together as a feedback. And then you can do some performance optimization, like if I give the graph theory server very near to my API, you'll see in the same data center that it comes between them is quite fast. So you don't really have to face problems with, you know, network mode, network house because of this kind of thing. So it's a rest API. Rest API. Right now I feel like, you know, this good word graph theory, it is also good word rest API also. But you have to add extra extra server things to make rest to graph theory. And if you say it is really complex like with updates, if you update one thing in updates like I don't know, if you don't know these things up your state, you can use more makes or something else. And I can, if you want to completely move on to graph theory, it's prefer to use something. There was a very nice question that I got recently. I was presenting this context API in one of the speakers in Bangalore. I took it, like for this half an hour, the same thing that I talked about there. After everything was done, one guy came to me and he said, what is context API? So the question was going, so, yeah, so can you, can a component be a provider and a consumer? Yeah. And this thing is there, the other thing, can you use, sorry, did I say can it with the context API? Or it is meant as an alternative to, yeah. So the only, the only condition is that the consumer has got to be inside your provider, because if they are outside your provider, the ball goes out of the water, so that a consumer has got to be wrapped within the provider, so that it knows who the provider is, otherwise it will not really get it. And that is where we had this default state that I showed you in the API, I said that while you create, for the create context, you can also provide a default value. That is in this kind of fallback situations, like let's say if you have a consumer, you don't have a provider, what is it that it is going to provide you? Provide you in such cases as default value, which is given. But the clean reasons are that you have your provider and inside that all your consumers. So that is why generally, even if there is a working case, let's say, an outlier or less, you would always have all our providers at the application level, so we will have all of them wrapping the application, so that now you are a kind of, you know, any kind of consumers inside, they will be inside of you. So how does the second question come? Can you use React for the Redux along with the API? Yeah. So definitely, so also, although Redux, you can use this context, but I think so that you can actually create multiple contexts within your applications. Even if you have your own context, you can also have Redux and link its own state management. So a situation where you have Redux, as well as your context API, will probably be an example of thinking, let's say. If you want to say that Redux will store only my applications and state, when I say application state, only the data which is related to my application. So I think what exactly is React doing? It's all a game of data, right? Your database is flowing between the servers and the users, and all these front-end frameworks, they are just kind of, maybe it visually looks good to the user. So all their components are nothing but data looking good to you. So if you say that I want to handle all the application related data in my Redux store, you can do that, and then you can say that these kind of cross-cutting concerns, like let's say, internet civilization, theming and all that, can be separated, so you can have both of them stick together. Okay, next. Yeah, Swami, this question is for you. I think this is just an extension of the question that you asked. So in your talk, you said the difference between Redux and the context API. So you said Redux has more tools and all. So apart from that, is there any advantage of context API or Redux like any performance and all? So like in one of our projects, we are using Redux. So will it make sense if I remove complete Redux and use the context API there? So Redux, although Internet uses context API, it is not just an over-context API, right? For example, it's the concept of a single store, the concept of using pure functions for Redux as well. So there is a lot of things, like an entire new design that they have come up with. It is just that they are using context API as an enabler to do it. So if you can write a code which is, you know, as good as that, let's say if it serves your purpose, it is actually not a very big library. It's a very small support. If you can do that, then it can have your own. But differently, it is actually a different question of when do I use a library versus when do I do my own? Most of the time, if you have a library which is serving your purpose, it is always good to use a library because see the number of places where this library has been tested. A lot of people think that they are already using it. There are so many contributors to it. So it has been very, very tested in a lot of different situations. So your application will actually enter being much more stable and not having to hiccups if you are using a good standard library. But if you are confident about what you are doing, let's say a lot of times a library provides this much and you only need this much. In such cases, you can do your own. Okay, I have a question for Shathrivedi. So what do you suggest, if an API call is failing, can we use it on boundaries for that? Skin use it. You have to release. You have to do there. Have you been using it in production? No. Next, I think, some British? Yes, I have a question. I have a mobile. So what we are exploring is the data for that. So Flutter seems to go react before mobile, not for... Flutter is very new. So one thing in software is you cannot get everything. If you have... you must compromise on performance or else you must compromise on speed. You must compromise on at least one thing. You cannot get everything in software. So if you really want to make the job that easy, it depends on what you have, what the resources you have. Mostly. Rather than if you try to train your people into something else, it takes more time, more energy and it won't be like the same application in the developers' lives, same experience with other technologies. One more question. I have two questions. Sorry, this question is a little too complex take-away idea. So you mentioned saying we can use context take-away when we're doing teamings and we're doing localizations. On the same lines, let's say we have an application which not just changes the font but also certain DOM elements are also changed and we need to separate something from the DOM based on that application. So in terms of that, does context take-away also have a limitation that we could use that it is defining for food or we're doing a context take-away? So context take-away is just like an empty room. So it doesn't really care about what you put inside the room and how you use that. So it doesn't really give any kind of restriction on how you can use it or in what purpose you should use it. It's just such a restriction that there has to be a provider who will provide the data and then whoever are the consumers will just let them know. So let's say this is more like I think a responsive to this and call it. Let's say you want to do your application differently or you want to have it differently or not? It's basically two different applications using same you know functionalities but you see it changes, you think it changes, plus few DOM elements like for example, for the DOM you can have extra orders in this application but on this application it's not enough. But something like this, in this case, you would have to make two separate contexts. So you would be looking the entire data of one particular application in that particular context so that it plays a role in your performance. Sorry. Sorry to disturb you. Can you please take a comment really for lunchtime? We are running out of the time. Sorry. Last one. Last one. Hi. This is a question for you, I think. How do you how do you start with what's the right model to make developers who are not writing their code say coming from an Angular or a Java background to start thinking in components and the React style of the way. You can use it. Yeah. So actually when I like when I came from NJ very well I really started immediately with React. I got to know about my functional thing which was going on. I just checked out how functional thing works and I just saw the implementation of it in React and that was one of the motivation for me to learn React. Then you think in terms of component it was really hard to think in terms of component. I cannot because if you design a page then you just start your slider and then you start it. I never think like yeah we divide it. I just I just keep on doing it again. But yeah when I just saw this kind of a thing it really made me think and that was one of the reason that I think that's your worshiping. Yeah. That is one of the reasons I come up with React and learning things. Yeah. I think that's time for the speakers answering the question. And thank you guys for asking. We'll talk soon. Yeah. There's always question. They are there. They are there. They hide away. And give feedback.