✏ Fix typos in docs/tutorial/code-structure.md, docs/tutorial/fastapi/multiple-models.md, docs/tutorial/fastapi/simple-hero-api.md, docs/tutorial/many-to-many/index.md

docs/tutorial/code-structure.md

@@ -170,7 +170,7 @@ Let's assume that now the file structure is:
 
 The problem with circular imports is that Python can't resolve them at <abbr title="While it is executing the program, as oposed to the code as just text in a file stored on disk.">*runtime*</abbr>.
 
-but when using Python **type annotations** it's very common to need to declare the type of some variables with classes imported from other files.
+But when using Python **type annotations** it's very common to need to declare the type of some variables with classes imported from other files.
 
 And the files with those classes might **also need to import** more things from the first files.
 

docs/tutorial/fastapi/multiple-models.md

@@ -361,7 +361,7 @@ And because we can't leave the empty space when creating a new class, but we don
 
 This means that there's nothing else special in this class apart from the fact that it is named `HeroCreate` and that it inherits from `HeroBase`.
 
-As an alternative, we could use `HeroBase` directly in the API code instead of `HeroCreate`, but it would show up in the auomatic docs UI with that name "`HeroBase`" which could be **confusing** for clients. Instead, "`HeroCreate`" is a bit more explicit about what it is for.
+As an alternative, we could use `HeroBase` directly in the API code instead of `HeroCreate`, but it would show up in the automatic docs UI with that name "`HeroBase`" which could be **confusing** for clients. Instead, "`HeroCreate`" is a bit more explicit about what it is for.
 
 On top of that, we could easily decide in the future that we want to receive **more data** when creating a new hero apart from the data in `HeroBase` (for example a password), and now we already have the class to put those extra fields.
 

docs/tutorial/many-to-many/index.md

@@ -60,7 +60,7 @@ Notice that each hero can only have **one** connection. But each team can receiv
 
 ## Introduce Many-to-Many
 
-But let's say that as **Deadpond** is a great chracter, they recruit him to the new **Preventers** team, but he's still part of the **Z-Force** team too.
+But let's say that as **Deadpond** is a great character, they recruit him to the new **Preventers** team, but he's still part of the **Z-Force** team too.
 
 So, now, we need to be able to have a hero that is connected to **many** teams. And then, each team, should still be able to receive **many** heroes. So we need a **Many-to-Many** relationship.