WEBVTT

1
00:00:00.709 --> 00:00:04.212
in this session. we will go over the basic API structure.  

2
00:00:04.629 --> 00:00:07.382
first. we will use `argon2` for password hashing.  

3
00:00:22.814 --> 00:00:24.816
install `argon2`.  

4
00:00:24.816 --> 00:00:28.737
make sure to install it inside the previously created conda environment.  

5
00:00:34.117 --> 00:00:38.163
this project follows the feature-based modularization pattern.  

6
00:00:39.122 --> 00:00:46.337
in a traditional MVC structure. components are separated into `routes/`. `services/`. and `models/`.  

7
00:00:46.337 --> 00:00:51.509
however. we structure features based on endpoint-centric architecture.  

8
00:00:52.260 --> 00:00:57.557
this ensures a 1:1 mapping between API design and code structure. 

9
00:00:57.557 --> 00:01:00.518
making maintenance and collaboration easier.  

10
00:01:01.061 --> 00:01:06.733
moreover. it follows a similar structure to Next.js API Routes.  

11
00:01:06.733 --> 00:01:10.653
allowing frontend developers to intuitively understand the project.  

12
00:01:11.112 --> 00:01:13.448
each feature (e.g.. `create_user`. `update_user`) has its own folder.  

13
00:01:13.448 --> 00:01:20.413
containing `router.py`. `schema.py`. and `crud.py` to maintain an independent structure.  

14
00:01:21.581 --> 00:01:25.126
by using FastAPI's Modular Router system.  

15
00:01:25.126 --> 00:01:27.837
routers can be registered automatically. 

16
00:01:27.837 --> 00:01:33.760
allowing new features to be added by simply creating a folder without modifying `main.py`.  

17
00:01:34.552 --> 00:01:40.183
automatically detect and register the `router.py` file inside the folder.  

18
00:01:41.392 --> 00:01:45.772
this maintains scalability like a microservices approach.  

19
00:01:45.772 --> 00:01:49.609
while allowing modularization within a single project.  

20
00:01:50.401 --> 00:01:56.324
since we are only explaining the structure.  
we will create a simple `get_test` API.  

21
00:01:57.450 --> 00:02:03.540
typically. we separate files into three main components: `router`. `schema`. and `crud`.  

22
00:02:04.499 --> 00:02:06.876
- `router` handles endpoint processing.  

23
00:02:07.335 --> 00:02:11.798
- `schema` manages data validation and API input/output models. 

24
00:02:12.215 --> 00:02:14.884
- `crud` handles database operations.  

25
00:02:15.593 --> 00:02:18.763
additional files can be added flexibly as needed.  

26
00:02:19.430 --> 00:02:21.975
however. the `router` file is essential. 

27
00:02:21.975 --> 00:02:26.312
while `schema` and `crud` files are used only when necessary. 

28
00:02:26.896 --> 00:02:31.276
still. in most cases. `router` and `schema` will be written together.  

29
00:02:31.693 --> 00:02:38.283
since we are not interacting with the database this time. we will not create a `crud` file.  

30
00:02:39.617 --> 00:02:43.705
now. let's examine the code for the `get_test` endpoint.  

31
00:02:44.497 --> 00:02:50.837
this endpoint returns a JSON response containing a `message` key with the value `"testget"`.  

32
00:02:51.337 --> 00:02:55.508
let's check if this is properly defined in `schema.py`.  

33
00:03:06.227 --> 00:03:10.440
we have also pre-created a `create_user` endpoint.  

34
00:03:10.440 --> 00:03:14.944
but it includes service logic such as password hashing and validation.  

35
00:03:15.945 --> 00:03:20.450
even if it looks complex. the core structure remains the same.  

36
00:03:21.951 --> 00:03:24.370
- `router` handles API endpoints. 

37
00:03:27.123 --> 00:03:31.461
- `schema` defines validation and API input/output models. 

38
00:03:32.795 --> 00:03:35.048
- `crud` handles database operations. 

39
00:03:37.592 --> 00:03:43.723
when managing the database in FastAPI. operations will follow a consistent pattern.  

40
00:03:44.891 --> 00:03:49.187
- common schema is defined in `share_schema.py`.  

41
00:03:50.772 --> 00:03:53.900
- common CRUD operations are defined in `share_crud.py`.  

42
00:03:55.193 --> 00:04:02.742
next time. we will cover one of the most critical parts: integrating the YOLO model with API endpoints.