DFD (Documentation-First Development) with FastAPI
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 131 | |
Author | ||
Contributors | ||
License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
Identifiers | 10.5446/69426 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
EuroPython 2024108 / 131
1
10
12
13
16
19
22
33
48
51
54
56
70
71
84
92
93
95
99
107
111
117
123
00:00
Software developerMultiplication signFlow separationService (economics)HypercubeServer (computing)Software engineeringComputer animationLecture/ConferenceMeeting/Interview
00:30
SoftwareTelecommunicationClient (computing)Server (computing)Arc (geometry)SineTelecommunicationPresentation of a groupServer (computing)Expert systemSoftware developerMusical ensembleClient (computing)Archaeological field surveyDependent and independent variablesCodePoint (geometry)Multiplication signInterface (computing)Latent heatError messageComputer animation
02:53
Content (media)Table (information)Client (computing)Server (computing)Design of experimentsCollaborationismPerspective (visual)Macro (computer science)CodeOpen setConservation of energySoftware engineeringPresentation of a groupSoftwareType theoryCodeStandard deviationClient (computing)Computing platformResultantOpen setLatent heatCollaborationismWeb 2.0Object (grammar)String (computer science)Category of beingServer (computing)Macro (computer science)Perspective (visual)WordSoftware frameworkDecision theoryMusical ensemble2 (number)CASE <Informatik>Computer animation
08:09
Open setModel theoryDependent and independent variablesCodeCodeOpen setMusical ensembleLatent heatComputer animation
09:14
Dependent and independent variablesDescriptive statisticsDisk read-and-write headBlock (periodic table)CodeRevision controlComputing platformDependent and independent variablesClient (computing)Metropolitan area networkComputer animation
10:04
Query languageParameter (computer programming)Dependent and independent variablesEmailScripting languageDesign of experimentsDependent and independent variablesDescriptive statisticsCodeComputer animation
10:48
Computer programmingMeta elementCodeClient (computing)Open setServer (computing)Open sourceSingle-precision floating-point formatCodeChainLatent heatClient (computing)Object (grammar)Server (computing)MetaprogrammierungFormal languageCategory of beingOpen setWebsiteMeta elementInterface (computing)Computer animation
11:50
Server (computing)Client (computing)Open sourceServer (computing)Client (computing)Interface (computing)Software developerComputer animation
12:29
Server (computing)Computer programmingMeta elementCodeMultiplication signInjektivitätWeb 2.0Service (economics)Open sourceDependent and independent variablesSoftware frameworkCodeServer (computing)Interface (computing)Computer animation
13:34
Model theoryCodeRootRouter (computing)Category of beingField (computer science)Data transmissionModel theoryDependent and independent variablesObject (grammar)Latent heatOpen setComputer animation
14:21
Dependent and independent variablesGUI widgetEmailCodeHypermediaOrdinary differential equationField (computer science)InformationSheaf (mathematics)Query languageParameter (computer programming)String (computer science)Client (computing)Field (computer science)Dependent and independent variablesParameter (computer programming)Model theoryMusical ensembleDescriptive statisticsCodeClient (computing)Latent heatComputer animation
15:14
LogicInterface (computing)CodeComputer animation
15:44
Formal languageError messageInformationCASE <Informatik>Revision controlDependent and independent variablesConsistencyObject (grammar)BootingFormal languageModel theoryType theoryField (computer science)Telephone number mappingAdditionValidity (statistics)Computer animation
17:10
Parameter (computer programming)Query languageString (computer science)Formal languageQuery languageRouter (computing)EmailInformationPseudodifferentialoperatorThermal expansionIntegerTelephone number mappingObject (grammar)Parameter (computer programming)Client (computing)EmailInformationCodeString (computer science)Field (computer science)AuthorizationValidity (statistics)Latent heatForm (programming)Computer animation
18:56
Field (computer science)String (computer science)EmailThermal expansionIntegerCategory of beingValidity (statistics)Field (computer science)Client (computing)Server (computing)Model theoryNeuroinformatikCodeLatent heatCategory of beingAuthorizationComputer animation
20:11
Client (computing)CodeServer (computing)Field (computer science)Online helpClient (computing)Category of beingElectric generatorAuthorizationCodeResultantEmailInformationFormal languageRevision controlComputer animation
21:05
Programmable read-only memoryRevision controlFlow separationAtomic packing factorMobile appRootInstance (computer science)Server (computing)Fundamental theorem of algebraSoftware developerConsistencyInstance (computer science)Revision controlConsistencyPattern languagePoint (geometry)Computer animation
21:53
Error messageDependent and independent variablesOpen setExact sequenceRoundingSocial classForm (programming)Latent heatField (computer science)Parameter (computer programming)Variable (mathematics)Exception handlingPredictabilityCodeOpen setMessage passingDependent and independent variablesClient (computing)outputElectric generatorSet (mathematics)Model theoryUniform resource locatorKey (cryptography)Configuration spaceRouter (computing)Error messageMathematical analysisComputer animation
23:01
Type theoryData structureGeneric programmingDependent and independent variablesClient (computing)CodeEndliche ModelltheorieDependent and independent variablesKey (cryptography)Type theoryModel theoryClient (computing)Field (computer science)Error messageData structureSocial classResultantPoint (geometry)Computer animation
24:18
Dependent and independent variablesService-oriented architectureEmailGUI widgetCodeHypermediaConsistencyDepth of fieldEndliche ModelltheorieConsistencyResultantKey (cryptography)Computer animation
24:51
CodeSoftware testingDependent and independent variablesError messageDigital filterInformationFormal languageFormal languageAuthorizationType theoryPredictabilityTelephone number mappingInformationGeneric programmingObject (grammar)Software developerParameter (computer programming)Level (video gaming)SoftwarePublic domainComputer animation
26:17
CodeDependent and independent variablesField (computer science)Generic programmingSoftware developerObject (grammar)Interface (computing)Telephone number mappingValidity (statistics)Pattern languageMobile appForm (programming)EmailComputer animation
27:11
Personal identification numberVulnerability (computing)Physical systemComputer animation
27:39
Control flowIntrusion detection systemServer (computing)Mobile appOpen set2 (number)Latent heatParameter (computer programming)Form (programming)Client (computing)Web 2.0Uniform resource locatorObject (grammar)Instance (computer science)Game controllerHookingInternet service providerPattern languageMobile appMultiplication signRevision controlForcing (mathematics)Proof theoryComputer animation
30:51
Hill differential equationOrdinary differential equationGame controllerMobile appUniform resource locatorOpen setIP addressException handlingClient (computing)Router (computing)Computer animation
31:37
Uniform resource locatorOpen setComputer animation
32:09
Point (geometry)Latent heatSoftware architectureRegular graphOpen setComputer animation
33:00
Network-attached storageArchitectureDiagramCodeOpen sourceData structurePresentation of a groupDatabaseEndliche ModelltheorieRevision controlDiagramRelational databaseSoftware architectureCodePresentation of a groupDatabaseMathematicsData structureComplex (psychology)Graph drawingSource codeSoftwareMetric systemPoint (geometry)Computer animation
33:52
Design of experimentsAnalytic continuationObject (grammar)TelecommunicationPoint (geometry)Software2 (number)Presentation of a groupLecture/ConferenceComputer animation
34:36
Presentation of a groupTelephone number mappingObject (grammar)SoftwareNeuroinformatikBoundary value problemValidity (statistics)Type theoryField (computer science)Generic programmingString (computer science)Revision controlConsistencyPattern languageEmailComputer animation
35:28
Design of experimentsInterface (computing)Proper mapSoftware developerPresentation of a groupComputer animation
35:57
Object (grammar)IP addressPublic domainGame controllerInformationInclusion mapCodeSocial classComputer animationLecture/Conference
36:39
Public domainControl flowSocial classInformationObject (grammar)Computer animation
37:18
Computer animation
Transcript: English(auto-generated)
00:04
My name is Taehyun, and I'm from South Korea, and I am into how to enhance the development experience. And I'm currently working as a software engineer at Carrot in South Korea. We aim to build a hyper-local community to serve several services such as buy and sell.
00:27
So, well, this is my first time to attend EuroPython, and it is a great honor to be here as a speaker. Today, I'm going to talk about and introduce the concept of the documentation-first development with Fest API.
00:47
So, before I start my presentation, I want to, like, quick-solve it. So, how many people who have not used Fest API before? So, can you raise your hands? Okay, and then, how many people have used Fest API before?
01:06
Oh, okay, thank you. Thanks for answering my survey, and today, I aim for the beginners and to give some tips of the Fest API. And so, I hope you can get some tips, even if you are already experts of the Fest API.
01:25
So, first things first, let's talk about the communication. There are two engineers, a client engineer and a server engineer. A client engineer wants to know the interface of the API.
01:45
So, like, question to the server engineers, like, how can I request to the server what I need to include in the request body? Or why I get this error response? Can you tell me the specification?
02:03
A server engineer can answer just like these by pointing to something, such as their codes. So, ask the interface of the request and point to something. So, as you can see, they ask an answer by verbal.
02:24
Well, it is still efficient when we need to be hurry to implement new features or enhance the features. However, what if a client engineer forgets the interface and asks more than twice or short times?
02:43
And impatient engineers can be irritated of this and say, ah, you already asked this before. So, this is terrible situation. So, are there more efficient ways? Are there more efficient ways by using software engineering?
03:03
We are engineers, hence, let's talk about the efficient ways with the software engineering in this presentation. So, what I will cover in this presentation are, first, the importance of the documentation. And in this presentation, the words document or the documentation mean the API documentation.
03:30
Second, the traditional methods to generate the documentation. Third, code-based documentation with fast API web framework.
03:43
Fourth, the efficient and safety ways how to manage the documentation. Lastly, the future of the documents. Then, what I will not cover in this presentation are, first, the details of the open API specification.
04:06
Second, the internal things of packages such as fast API. Third, the detailed explanation of types in Python. Lastly, the silver bullet.
04:22
The things I will share are not the best solution for all cases. Hence, you need to move it over by your situations. So, now let's begin to the importance of the documents. So, why? Why the documentation is so important?
04:44
Let's think the importance as the collaborate perspective. There are two types of collaboration. First, macro collaboration, which means to collaborate with external people. Second, micro collaboration, which means communicate with the internal peoples.
05:07
So, I will tell you first the macro collaboration. As I aforementioned, a client engineer and a server engineer can communicate by verbal.
05:21
But what if there are tons of client engineers and server engineers? Regardless the size of team, they still need to communicate. So, we realize that we need some standard to communicate well.
05:40
But what standard? What can we choose for this standard? We can usually use the open API specification for the standard. One of the biggest advantage of this specification is that client engineers can generate their code
06:01
through the specification. So, let me show the example. For example, if you define the book object which has a property called name as a string type, client engineers can generate their codes easily by using some packages such as open API TypeScript culture.
06:24
So, the result generates the codes in TypeScript by the specification. Now, let's talk about the micro collaboration. Server engineers also communicate each other.
06:42
So, they discuss about how to refactor, how to fix the bugs, or how to enhance features or performance. Consequently, they also need standard because they need standard for the better decisions or discussions.
07:02
So, when we talk about the importance of the documentation, we need to consider that all the engineers need to communicate each other. And for what? For better software. To make software better than before.
07:24
So, if there is a well-produced document in our team or company, we can grow our software efficiently because we can discuss based on the documents and check what we need to.
07:44
Now, let's move on to the next agenda. So, how we generate the documentation before? There are three ways. First, using comments. Second, using documentation tools.
08:01
Lastly, using API client platforms. So, let's talk about comments first. You can generate documents based on the open API specification with comments. Some packages leave the comments and generate the documents with it.
08:24
So, you need to know the specification of comments too. The details of the package. Learning the details of the package to generate the documents is also inefficient, but the most crucial disadvantage of using comments is that it needs to update the comments if the schema is changed.
08:49
But we have already experienced that it does not work well because we usually forget to update the comments if the schemas or codes are changed too.
09:01
So, now let's talk about the documentation tools. There are lots of tools such as Notion and Google Docs. You can create documents by using Notion with code blocks and descriptions or headings.
09:22
So, it is easy to generate and write the documents. So, we also can manage the history or revision or version of the documents. But as you can think, we still need to update the documentation and the Notion when if the schema is changed, just like the comments.
09:46
What about API client platforms? A postman is a well-known API client platform. So, you can generate the documents through the postman by using the responses of the APIs.
10:03
As you can see, you can also add some description of the APIs. And the postman uses the response as the examples in the documents. But we still need to update the documents in the postman if the schema is changed,
10:25
just like the comments or the documentation tools. Well, the main problem is the relationship between the codes and the documents. So, we need to synchronize the codes and documents to decrease the human errors,
10:44
such as forgetting to update the comments. So, can we synchronize automatically? Moreover, which one should be the single source of truth, code or the document?
11:02
Let's think about the documents as the single source of the truth. As I mentioned before, client engineers can generate their code through the OpenAPI specification. We define the book object with a name property, and it generates the TypeScript code as an interface.
11:27
Not only the client engineers, server engineers also can generate their codes by using the specification. For example, if we use OAPI code chain in Go language packages,
11:41
we can generate the server-side codes in Go through the specification. So, this is kind of called metaprogramming. Now, all the engineers, both client engineers and server engineers, can participate and fix the schemas.
12:00
Because the schema is the single source of the truth. So, it is really useful because client engineers also can participate to fix the interfaces. So, if you concern the documents as the single source of the truth, it can be documentation-first development.
12:25
But what about microservices? If server services need to use the same API of our server, they may just want to use our API, not to participate to fix or discuss about the interfaces.
12:46
Moreover, it is inefficient to make all engineers to fix the schemas. So, it is our own responsibility to manage the documentation. So, what about codes?
13:01
Let's make codes the single source of the truth. It is time to talk about the FAST API. So, FAST API is a Python web framework. It internally used Pydantic and Starlet. Well, there are lots of advantages of the FAST API, such as being easy to create async API or dependency injection.
13:28
But I want to focus on auto-generated documentation. As I said, FAST API uses the Pydantic, and we can define model with Pydantic.
13:43
You can simply think that this is a kind of GTO, a data transfer object. Moreover, we can define the fields of the model, such as the name of the book, and it becomes a property of the book in the OpenAPI specification.
14:06
Now, when you create a router, which means an API, we can use the model we defined as a response model. We build the model by using the Pydantic.
14:22
Then, FAST API generates the documents automatically by using the model we defined. As you can see, it creates an example of the response by using parameter called the examples of the field.
14:43
So, additionally, we can also add comments to describe the details of the APIs. FAST API also creates the comments as a description of the APIs automatically. So, lastly, there is also a schema of the model.
15:04
So, as we can see, client engineers can generate their codes by using this specification, this schema. But wait, you can think that, isn't it code first instead of documentation first?
15:24
But no, it is documentation first, but generated by the codes. We don't implement any business logic or the details of the API. So, we just create the documents, the interface first. So, this is still the documentation first.
15:45
Now, let's talk about the efficiency. How can we write the documents better? We can think clearness and consistency for the efficiency.
16:01
Before we talk about the details, we have new requirements. We need to add country and language information of the books. So, we need to consider some cases. Are countries and languages limited? Do we need to filter books by countries and languages?
16:25
Or are there any additional error responses to create? So, let's reserve the issues by moving on to clearness first. So, we can think three aspects, three things about when we talk about the clearness.
16:44
The field, the validation, and the version. We can add some fields in the model to meet our requirements. As you can see, we set the type of the fields as literal and enum objects.
17:04
We can also reuse the object in the loader. Now, what happens in the documentation? Fast API uses these objects, literal and the enum objects, to create parameters automatically.
17:24
Moreover, it uses the members as examples, such as USA. So, now another requirement. We need to make authors to register their information, such as name or email.
17:45
So, our authors need to be over 19 years old? Or do we need to show their full name? Let's talk about the validation first. We need to add authors of the books, and there are some restrictions.
18:05
We can use GE parameter, which stands for greater and equal, to restrict the minimum age of the authors. We also can use the email string object provided by Pylantic to specify the email fields as email form.
18:26
Now, if you check the schema that Fast API creates, it uses those validations on the schema, too. So, age must be over 19 years old, and the email field must be the form of the email.
18:45
It is helpful when the client engineers need to know the details and generate the codes by this specification. So, Fast API can define validation of the field automatically in the documentation.
19:07
We can also use this computed field as a decorator to combine two fields in Pylantic. Computed field helps to generate a new field by using authors in the model.
19:21
Then, as you can see, it uses the first name and the last name to join and create the full name. Now, you can see there is a name field which is generated by joining two fields, first name and the last name.
19:43
And you can also see that it is a lead omni, which means clients can include the name fields when they request to the server. They can just read it. So, as I mentioned before, clients can generate their codes with these specifications,
20:02
and they will not make any mistakes because it informs that it is a lead omni property. So, Fast API and Pylantic help to generate a new field efficiently and also make lead omni to inform the clients
20:22
this field is generated by the server, not by you, not by the clients. As a result, I can summarize what we did. We analyzed our requirements and generated documents by codes to discuss about it.
20:43
Sometimes, we need to separate the versions of the APIs. For example, we also need to handle the two new requirements. We add countries and language information of the books, and also we need to make authors to register their information, such as email.
21:06
You can separate the instance of Fast API for each version. Then, generate a loot instance and mount the subapps to the loot instance. Fast API supports the subapps pattern by using this mount method.
21:25
As you can see, Fast API generates the first version of API documents in V1 docs endpoint, and the second version in the V2 docs endpoint.
21:44
Now, let's move on to consistency. Consistency refers to predictability. This is a form of the error response which Fast API generates. We need to use these three fields, location, message, input, on our custom exceptions for the predictability.
22:12
It might be better to inform our clients at the same way, because sometimes they need to use the error analysis. So, we need to generate the same form of the error response that Fast API creates.
22:25
We can use JSON schema extra variable in the config class. We can define our customized values of OpenAPI specification, such as examples.
22:44
Then, we can set status code as a key and model we defined with customized examples with JSON schema extra variable as a value. In the responses, the parameter at the router layer.
23:01
Consequently, Fast API generates the error examples with our customized models. You can see that the status code 401 and 403 has their own examples. We can also use generic for common structure of success responses, such as the data key.
23:29
As you can see, if we pass the response with a unified structure, client engineers always predict that they can access the leisure with the key named the data.
23:45
We can define customized type by using type bar in Python and the type code data bounds to base model. Hence, we can pass our models defined by the pydantic.
24:01
Then, we can use generic to define our fields dynamically. Now, pass the real model that we defined with the using the pydantic with base model class. As a result, Fast API can use the details of each models.
24:24
Moreover, all the results are included in the same key code data. We talk about the clearness and consistency to generate the better documents. So, why we need to concern the clearness and consistency?
24:46
Why we need well-produced documents? Most of those need to be changed or fixed because the requirements are always changing.
25:01
As you can see, we cost much lower on analyzing the requirements and design stages. Thus, we can use the well-produced documentation, especially documentation-first, development philosophy to decline these costs because we embrace any changes
25:24
or discuss more details efficiently these two stages, requirements and design. We need to handle the new requirements adding countries or languages information of the books.
25:42
Then, we build a documentation-first by using some pydantic types such as literal or the enum object. We use these objects as parameters of the API. Also, use JSON schema extra and generic type with customized type for the predictability.
26:07
Not only handling countries and languages, we also handle to add author to the domain. So, what we did first, we use subapps pattern for versioning of APIs,
26:26
enum and literal objects to limit deep values, some validation in pydantic such as GE, which stands for greater and equal, and email form.
26:41
Creating new fields by using existed field in pydantic and generics to create unified responses. Consequently, we can build both interfaces and documents by codes. So, it helps to enhance the development experience because we don't need to manage separately the codes and documents.
27:12
Now, let's move on the safety. How can we manage our documents much safer?
27:20
But wait, why is the safety important when we manage the documents? Because of the vulnerability. External people can spot the weakness of our APIs or our systems through the documents.
27:40
There are three ways to manage your documents safer. First, exclude all APIs in the documents. Second, exclude only specific APIs such as webhook or health check endpoint for the readiness prove on Kubernetes.
28:00
Lastly, control the access or permissions of the users. Let's talk about the how can we exclude all the APIs. Well, FastAPI generates three documents automatically. First, the JSON schema as a form of the OpenAPI specification at OpenAPI.json endpoint.
28:29
Second, API documents that engineers can see based on the swagger at docs endpoint. And lastly, on other documents which also use the OpenAPI specification but not using swagger.
28:45
The add redoc endpoint. So, FastAPI object has three parameters related with the documents. OpenAPI URL, docs URL, and the redoc URL.
29:05
If you want to unpublish all the documents, you need to handle the OpenAPI URL parameter. If you only handle docs URL or redoc URL, you still publish the documents and external people can access the specification of your APIs.
29:25
So, please be careful to handle these parameters. Now, let's move on how we can exclude only specific APIs. Sometimes, we don't want to include some APIs such as webhook endpoints from the external providers
29:43
or house check endpoints for the readiness proven Kubernetes because our clients don't need to know the details of them. You can use include in schema parameter when you register the API to the FastAPI instance.
30:03
If you pass force to the value of the parameter, FastAPI does not publish these APIs. As I mentioned, it is useful for some APIs, clients that don't need to know that. Now, it's time to talk about the access control.
30:25
What if we need to serve our APIs on both public and private? Then, how can you make our teams can only see the documents, not on the public? You can also use subapps pattern as we talked during the versioning of the APIs.
30:46
You can separate the apps, public and the private. Then, just unpublish the documents on the public apps by using OpenAPI URL and publish documents of private apps.
31:03
You can also use the dependency for the access control. In this example, we limit the IP address to access the documents if IP address of client is not local.
31:21
So, it returns forbidden exception if the client is not in the local host. You can add this dependency in routers by using depends in FastAPI. But wait, why we need to handle two APIs, the OpenAPI.json and the talks?
31:46
As you can see, we add the dependency in two APIs. Let's think about how FastAPI generates the documents. As we saw before, we need to handle OpenAPI URL to unpublish the whole documents
32:03
and as you can see, there is this special endpoint, OpenAPI.json. So, FastAPI generates the JSON of schemas at OpenAPI.json endpoint. Then, it used these values to generate the documents at docs endpoint with Swagger.
32:26
This is why external people can still access two endpoints, OpenAPI.json and the docs endpoint if you only block the redock. So, last but not least, you also need to use getOpenAPI method
32:42
and the getSwagger UI HTML. So, FastAPI generates OpenAPI specification by using getOpenAPI method and documents based on Swagger by using this getSwagger UI HTML. Not only the API documentations, we can also think about our software architecture
33:07
and entity relationship diagram for our relational databases. What about using packages called Emerge to show the structure of our source code with commands?
33:21
Emerge has to visualize your structures, metrics, dependencies or anything complexity of the software as a graph visualization. What about using packages called ER alchemy to show entity relational diagram of the database written by SQL alchemy?
33:44
Maybe it might be better it reflects the change of our diagrams to our codes or vice versa. The point is that we need to think how we can grow our software continuously with an efficient communication such as well-produced documents.
34:05
Now, let's recap the presentation. We talk about the importance of the documentation for continued growth of the software. Second, we looked several ways of generating and managing documents
34:21
such as using comments or documentation tools like Notion or Google Docs and Postman. Third, we discussed to use literal and enum object to provide the clearness of the documents. Moreover, we talked how we can give consistency of our documents by using customized types and generics.
34:50
Additionally, we use internal validations such as GE greater than equal and email string object and use computed field as a decorator to create a new field efficiently.
35:06
Also, we can separate our API versions and boundaries such as public and private by using sub-apps patterns in Fest API. Lastly, we can use the dependency with depends in the Fest API to control the access of the documents.
35:29
The most important thing is that we need to generate the documents first to meet requirements properly. Then, Fest API helps us to create interfaces and it enhances our development experience.
35:46
So, this is my end of presentation. Thanks for listening to my presentation.
36:00
Thank you very much, Taehyun. We have a few minutes for some questions. Okay, yeah, we have one question there. You showed here with the access codes. Please speak into the microphone so we can hear. Is it okay now? Okay, alright. Yeah, you showed earlier that you can, let's say, make it private by only giving access to some IP address.
36:26
But is it also possible to include domain users, for example, or somehow give access based on the domain user access? You mean like control the access based on the domains? Yes, we can, because the Fest API gives the weakest object with the weakest class and it has the host or domain information.
36:49
So, you can still access the domain or IP address, whatever you want. Thank you. Any other questions?
37:03
Okay, so in the absence of any questions, I think the current break we have is for lunch. So, we'll have a long break for lunch. Thank you all for joining the session and see you around.