WEBVTT 00:01.280 --> 00:03.000 Hello everyone and welcome. 00:03.320 --> 00:07.680 In this particular video we will learn about client server architecture. 00:08.080 --> 00:11.600 It is one of those fundamental that you need to understand. 00:12.800 --> 00:16.320 MCP relies heavily on the client server architecture. 00:16.320 --> 00:20.240 So it's important for us to learn about client server architecture. 00:20.840 --> 00:26.560 Now if you are already familiar with how client server architecture works, then please feel free to 00:26.600 --> 00:29.320 skip this video and move on to the next one. 00:30.480 --> 00:37.240 If you want to understand and have a refresher on client server architecture, then please stay on this 00:37.240 --> 00:45.160 video and we will cover why client server matters and how it solves the problems that we're connected 00:45.160 --> 00:45.360 to. 00:45.400 --> 00:46.440 AI agents. 00:46.640 --> 00:51.720 Having said that, let's move on to the client server communication. 00:53.200 --> 01:00.210 So there are three main components involved in the client server architecture a client is a typical 01:00.450 --> 01:06.090 application, any computer or device that requests services or resources. 01:06.330 --> 01:13.410 Server is a powerful computer or software that provides services and resources to clients. 01:13.570 --> 01:17.890 And then there is a communication that happens over internet. 01:18.890 --> 01:26.610 This is a standardized protocol that establishes reliable data exchange between client and server components. 01:27.010 --> 01:29.370 So now how the process works. 01:29.570 --> 01:37.530 A client on the left hand side of the image sends a request, such as a web page or access in a database. 01:37.970 --> 01:41.810 Then this request travels over network to reach server. 01:42.210 --> 01:49.770 Then the server processes the request and prepares the requested data for service, and the response 01:49.770 --> 01:52.530 then is sent back to the client. 01:52.690 --> 02:00.550 And then client displays the responses on the web page or uses the response to do further processing. 02:01.110 --> 02:06.790 This is typically how the client work application communicates over internet. 02:07.110 --> 02:15.670 So this is where we have a critical role for established standards like HTTP or FTP provide a critical 02:15.670 --> 02:23.750 role for software development because they establish common protocols that allow different systems to 02:23.790 --> 02:27.510 communicate effectively without standards. 02:27.990 --> 02:35.270 Every system would essentially speak its own language, making integration nearly impossible. 02:35.910 --> 02:43.390 So now let's understand a little bit more about Rest API and the challenges that Lem has using APIs. 02:44.150 --> 02:51.150 So Rest API is essentially representational state transfer, which is a widely used protocol for communicating 02:51.710 --> 02:53.230 using web APIs. 02:53.230 --> 02:59.360 You interact with Rest API daily through social media, messaging apps and mobile applications. 02:59.680 --> 03:08.800 It has a standard in terms of using methods HTTP, post, get, put, delete, and the responses are 03:08.800 --> 03:11.640 also structured in JSON format. 03:12.200 --> 03:14.360 So now why standards matter? 03:14.800 --> 03:18.640 It provides a universal language for systems to communicate. 03:18.640 --> 03:25.600 When companies they follow Rest standards, developers can essentially connect and use their services 03:25.600 --> 03:27.520 with those standards in place. 03:28.680 --> 03:34.000 So this is where the engineering principle relies on establishing standards. 03:34.280 --> 03:37.600 They're essentially what makes complex systems possible. 03:38.160 --> 03:45.360 Without standards, every company would create unique systems, making it nearly impossible to scale 03:45.360 --> 03:47.320 and manage a complex system. 03:48.560 --> 03:53.720 So the problem of right language model connecting with tools is very prominent. 03:54.040 --> 04:02.420 Think of large language model connecting to a tool that speaks different languages English, Spanish, 04:02.620 --> 04:03.580 Japanese. 04:04.140 --> 04:11.420 Every service provides their API contract differently, requiring the information to be set up differently. 04:12.460 --> 04:20.340 The real problem here is that you cannot have APIs or services that gives responses in different formats 04:20.340 --> 04:21.940 and different standards. 04:22.260 --> 04:27.500 It is nearly impossible for law or any technology to scale. 04:28.060 --> 04:36.660 This is where MCP comes to rescue, and it's important how MCP creates standard that Lem can relay on. 04:37.140 --> 04:40.980 And all the underlying services also has to rely on. 04:40.980 --> 04:50.300 And making this scalable, manageable and seamless across the technology that we are evolving into. 04:50.780 --> 04:51.540 Thank you. 04:52.020 --> 04:53.980 I'll see you in the next video.