diff --git a/docs/essential/best-practice.md b/docs/essential/best-practice.md
index 6de2103b..483e2730 100644
--- a/docs/essential/best-practice.md
+++ b/docs/essential/best-practice.md
@@ -18,15 +18,15 @@ head:
Elysia is a pattern-agnostic framework, leaving the decision of which coding patterns to use up to you and your team.
-However, there are several concerns from trying to adapt an MVC pattern [(Model-View-Controller)](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) with Elysia, and we found it's hard to decouple and handle types.
+However, there are several concerns when trying to adapt an MVC pattern [(Model-View-Controller)](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) with Elysia, and we found it hard to decouple and handle types.
-This page is a guide on how to follow Elysia structure best practices combined with MVC pattern but can be adapted to any coding pattern you like.
+This page is a guide on how to follow Elysia structure best practices combined with the MVC pattern, but it can be adapted to any coding pattern you prefer.
## Folder Structure
Elysia is unopinionated about folder structure, leaving you to **decide** how to organize your code yourself.
-However, **if you don't have a specific structure in mind**, we recommend a feature-based folder structure. Where each feature has its own folder containing controllers, services, and models.
+However, **if you don't have a specific structure in mind**, we recommend a feature-based folder structure where each feature has its own folder containing controllers, services, and models.
```
| src
@@ -46,7 +46,7 @@ However, **if you don't have a specific structure in mind**, we recommend a feat
| index.ts
```
-This structure allows you to easily find and manage your code, and keep related code together.
+This structure allows you to easily find and manage your code and keep related code together.
Here's an example code of how to distribute your code into a feature-based folder structure:
@@ -144,12 +144,12 @@ Each file has its own responsibility as follows:
- **Service**: Handle business logic, decoupled from Elysia controller if possible.
- **Model**: Define the data structure and validation for the request and response.
-Feels free to abstract this structure to your own needs, and use any coding pattern you like.
+Feel free to adapt this structure to your needs and use any coding pattern you prefer.
## Method Chaining
Elysia code should always use **method chaining**.
-As Elysia type system is complex, every methods in Elysia returns a new type reference.
+As Elysia's type system is complex, every method in Elysia returns a new type reference.
**This is important** to ensure type integrity and inference.
@@ -181,7 +181,7 @@ app.get('/', ({ store: { build } }) => build)
app.listen(3000)
```
-We recommend to **always use method chaining** to provide an accurate type inference.
+We recommend to **always use method chaining** to provide accurate type inference.
## Controller
> 1 Elysia instance = 1 controller
@@ -257,15 +257,15 @@ Service is a set of utility/helper functions decoupled as a business logic to us
Any technical logic that can be decoupled from controller may live inside a **Service**.
-There're 2 types of service in Elysia:
+There are 2 types of service in Elysia:
1. Non-request dependent service
2. Request dependent service
### ✅ Do: Abstract away non-request dependent service
-We recommended to abstract a service class/function away from Elysia.
+We recommend abstracting a service class/function away from Elysia.
-If the service or function doesn't tied to HTTP request or access a `Context`. It's recommended to abstract it as a static class or function.
+If the service or function isn't tied to an HTTP request or doesn't access a `Context`, it's recommended to implement it as a static class or function.
```typescript
import { Elysia, t } from 'elysia'
@@ -291,7 +291,7 @@ If your service doesn't need to store a property, you may use `abstract class` a
### ✅ Do: Request dependent service as Elysia instance
-**If the service is a request dependent service** or need to process HTTP request. We recommended to abstract it as Elysia instance to ensure type integrity and inference:
+**If the service is a request-dependent service** or needs to process HTTP requests, we recommend abstracting it as an Elysia instance to ensure type integrity and inference:
```typescript
import { Elysia } from 'elysia'
@@ -318,14 +318,14 @@ const UserController = new Elysia()
```
::: tip
-Elysia handle [plugin deduplication](/essential/plugin.html#plugin-deduplication) by default so you don't have to worry about performance, as it's going to be Singleton if you specified a **"name"** property.
+Elysia handles [plugin deduplication](/essential/plugin.html#plugin-deduplication) by default, so you don't have to worry about performance, as it will be a singleton if you specify a **"name"** property.
:::
### ✅ Do: Decorate only request dependent property
-It's recommended to `decorate` only request dependent property, such as `requestIP`, `requestTime`, or `session`.
+It's recommended to `decorate` only request-dependent properties, such as `requestIP`, `requestTime`, or `session`.
-Overusing decorator may tied your code to Elysia making it harder to test, and reuse.
+Overusing decorators may tie your code to Elysia, making it harder to test and reuse.
```typescript
import { Elysia } from 'elysia'