docs(): minor tweaks

kamilmysliwiec · kamilmysliwiec · commit a56d1858f0dd · 2021-08-09T11:40:16.000+02:00
diff --git a/content/recipes/mikroorm.md b/content/recipes/mikroorm.md
@@ -1,27 +1,19 @@
 ### MikroORM
 
-This recipe is here to help users getting started with MikroORM in NestJS. MikroORM is the TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. It is well maintained and the maintainer responds quick to questions and issues. It is a great alternative to TypeORM and migration from TypeORM should be fairly easy.
+This recipe is here to help users getting started with MikroORM in Nest. MikroORM is the TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns. It is a great alternative to TypeORM and migration from TypeORM should be fairly easy. The complete documentation on MikroORM can be found [here](https://mikro-orm.io/docs).
 
-[The complete documentation on MikroORM can be found here.](https://mikro-orm.io/docs)
-
-> info **info** @mikro-orm/nestjs is a third party package and not managed by the NestJS core team. Please bring any issues found with the library to the [appropriate repository](https://github.com/mikro-orm/nestjs)
+> info **info** `@mikro-orm/nestjs` is a third party package and is not managed by the NestJS core team. Please, report any issues found with the library in the [appropriate repository](https://github.com/mikro-orm/nestjs).
 
 #### Installation
 
 Easiest way to integrate MikroORM to Nest is via [`@mikro-orm/nestjs` module](https://github.com/mikro-orm/nestjs).
-Simply install it next to Nest, MikroORM and underlying driver: 
+Simply install it next to Nest, MikroORM and underlying driver:
 
 ```bash
-$ yarn add @mikro-orm/core @mikro-orm/nestjs @mikro-orm/mysql       # for mysql/mariadb
+$ npm i @mikro-orm/core @mikro-orm/nestjs @mikro-orm/mysql # for mysql/mariadb
 ```
 
-or
-
-```bash
-$ npm i -s @mikro-orm/core @mikro-orm/nestjs @mikro-orm/sqlite      # for sqlite
-```
-
-MikroORM also supports `postgres` and `mongo`. See the [official docs](https://mikro-orm.io/docs/usage-with-sql/) for all the drivers.
+MikroORM also supports `postgres`, `sqlite`, and `mongo`. See the [official docs](https://mikro-orm.io/docs/usage-with-sql/) for all drivers.
 
 Once the installation process is completed, we can import the `MikroOrmModule` into the root `AppModule`.
 
@@ -43,7 +35,7 @@ export class AppModule {}
 
 The `forRoot()` method accepts the same configuration object as `init()` from the MikroORM package. Check [this page](https://mikro-orm.io/docs/configuration) for the complete configuration documentation.
 
-Alternatively we can [configure the CLI](https://mikro-orm.io/docs/installation#setting-up-the-commandline-tool) by creating a configuration file `mikro-orm.config.ts` and then call the `forRoot()` without any arguments. This won't work when you use a build tools that use tree shaking. 
+Alternatively we can [configure the CLI](https://mikro-orm.io/docs/installation#setting-up-the-commandline-tool) by creating a configuration file `mikro-orm.config.ts` and then call the `forRoot()` without any arguments. This won't work when you use a build tools that use tree shaking.
 
 ```typescript
 @Module({
@@ -59,32 +51,29 @@ Afterward, the `EntityManager` will be available to inject across entire project
 
 ```ts
 import { MikroORM } from '@mikro-orm/core';
-import { EntityManager } from '@mikro-orm/mysql'; // Import EntityManager from your driver package or `@mikro-orm/knex`
+// Import EntityManager from your driver package or `@mikro-orm/knex`
+import { EntityManager } from '@mikro-orm/mysql';
 
 @Injectable()
 export class MyService {
-
-    constructor(private readonly orm: MikroORM,
-                private readonly em: EntityManager) {
-    }
-
+  constructor(
+    private readonly orm: MikroORM,
+    private readonly em: EntityManager,
+  ) {}
 }
 ```
 
-> info **info**  Notice that the `EntityManager` is imported from the `@mikro-orm/driver` package, where driver is `mysql`, `sqlite`, `postgres` or what driver you are using.
-> 
-> In case you have `@mikro-orm/knex` installed as a dependency, you can also import the `EntityManager` from there.
+> info **info** Notice that the `EntityManager` is imported from the `@mikro-orm/driver` package, where driver is `mysql`, `sqlite`, `postgres` or what driver you are using. In case you have `@mikro-orm/knex` installed as a dependency, you can also import the `EntityManager` from there.
 
 #### Repositories
-MikroORM supports the repository design pattern. For every entity we can create a repository. Read the complete [documentation on repositories here](https://mikro-orm.io/docs/repositories). To define which repositories shall be registered in the current scope you can use the `forFeature()` method. For example, in this way:
 
-> info **info**  You should **not** register your base entities via `forFeature()`, as there are no
-> repositories for those. On the other hand, base entities need to be part of the list
-> in `forRoot()` (or in the ORM config in general).
+MikroORM supports the repository design pattern. For every entity we can create a repository. Read the complete documentation on repositories [here](https://mikro-orm.io/docs/repositories). To define which repositories should be registered in the current scope you can use the `forFeature()` method. For example, in this way:
+
+> info **info** You should **not** register your base entities via `forFeature()`, as there are no
+> repositories for those. On the other hand, base entities need to be part of the list in `forRoot()` (or in the ORM config in general).
 
 ```typescript
 // photo.module.ts
-
 @Module({
   imports: [MikroOrmModule.forFeature([Photo])],
   providers: [PhotoService],
@@ -110,10 +99,8 @@ In this way we can inject the `PhotoRepository` to the `PhotoService` using the
 export class PhotoService {
   constructor(
     @InjectRepository(Photo)
-    private readonly photoRepository: EntityRepository<Photo>
+    private readonly photoRepository: EntityRepository<Photo>,
   ) {}
-
-  // ...
 }
 ```
 
@@ -123,33 +110,26 @@ When using custom repositories, we can get around the need for `@InjectRepositor
 decorator by naming our repositories the same way as `getRepositoryToken()` method do:
 
 ```ts
-export const getRepositoryToken = <T> (entity: EntityName<T>) => `${Utils.className(entity)}Repository`;
+export const getRepositoryToken = <T>(entity: EntityName<T>) =>
+  `${Utils.className(entity)}Repository`;
 ```
 
 In other words, as long as we name the repository same was as the entity is called,
 appending `Repository` suffix, the repository will be registered automatically in
-the Nest.js DI container.
-
-`**./author.entity.ts**`
+the Nest DI container.
 
 ```ts
+// `**./author.entity.ts**`
 @Entity()
 export class Author {
-
   // to allow inference in `em.getRepository()`
   [EntityRepositoryType]?: AuthorRepository;
-
 }
-```
 
-`**./author.repository.ts**`
-
-```ts
+// `**./author.repository.ts**`
 @Repository(Author)
 export class AuthorRepository extends EntityRepository<Author> {
-
   // your custom methods...
-
 }
 ```
 
@@ -159,26 +139,24 @@ return, we do not need the `@InjectRepository()` decorator anymore:
 ```ts
 @Injectable()
 export class MyService {
-
-  constructor(private readonly repo: AuthorRepository) { }
-
+  constructor(private readonly repo: AuthorRepository) {}
 }
 ```
 
 #### Load entities automatically
 
-> info **info**  `autoLoadEntities` option was added in v4.1.0 
+> info **info** `autoLoadEntities` option was added in v4.1.0
 
-Manually adding entities to the entities array of the connection options can be 
-tedious. In addition, referencing entities from the root module breaks application 
-domain boundaries and causes leaking implementation details to other parts of the 
+Manually adding entities to the entities array of the connection options can be
+tedious. In addition, referencing entities from the root module breaks application
+domain boundaries and causes leaking implementation details to other parts of the
 application. To solve this issue, static glob paths can be used.
 
-Note, however, that glob paths are not supported by webpack, so if you are building 
-your application within a monorepo, you won't be able to use them. To address this 
-issue, an alternative solution is provided. To automatically load entities, set the 
-`autoLoadEntities` property of the configuration object (passed into the `forRoot()` 
-method) to `true`, as shown below: 
+Note, however, that glob paths are not supported by webpack, so if you are building
+your application within a monorepo, you won't be able to use them. To address this
+issue, an alternative solution is provided. To automatically load entities, set the
+`autoLoadEntities` property of the configuration object (passed into the `forRoot()`
+method) to `true`, as shown below:
 
 ```ts
 @Module({
@@ -192,44 +170,42 @@ method) to `true`, as shown below:
 export class AppModule {}
 ```
 
-With that option specified, every entity registered through the `forFeature()` 
-method will be automatically added to the entities array of the configuration 
+With that option specified, every entity registered through the `forFeature()`
+method will be automatically added to the entities array of the configuration
 object.
 
-> info **info**  Note that entities that aren't registered through the `forFeature()` method, but 
-> are only referenced from the entity (via a relationship), won't be included by 
+> info **info** Note that entities that aren't registered through the `forFeature()` method, but
+> are only referenced from the entity (via a relationship), won't be included by
 > way of the `autoLoadEntities` setting.
 
-> info **info**  Using `autoLoadEntities` also has no effect on the MikroORM CLI - for that we 
+> info **info** Using `autoLoadEntities` also has no effect on the MikroORM CLI - for that we
 > still need CLI config with the full list of entities. On the other hand, we can
 > use globs there, as the CLI won't go thru webpack.
 
 #### Request scoped handlers in queues
 
-> info **info**  `@UseRequestContext()` decorator was added in v4.1.0 
+> info **info** `@UseRequestContext()` decorator was added in v4.1.0
 
-As mentioned in the [docs](https://mikro-orm.io/docs/identity-map), we need a clean state for each request. That is handled automatically thanks to the `RequestContext` helper registered via middleware. 
+As mentioned in the [docs](https://mikro-orm.io/docs/identity-map), we need a clean state for each request. That is handled automatically thanks to the `RequestContext` helper registered via middleware.
 
 But middlewares are executed only for regular HTTP request handles, what if we need
-a request scoped method outside of that? One example of that is queue handlers or 
-scheduled tasks. 
+a request scoped method outside of that? One example of that is queue handlers or
+scheduled tasks.
 
 We can use the `@UseRequestContext()` decorator. It requires you to first inject the
-`MikroORM` instance to current context, it will be then used to create the context 
-for you. Under the hood, the decorator will register new request context for your 
-method and execute it inside the context. 
+`MikroORM` instance to current context, it will be then used to create the context
+for you. Under the hood, the decorator will register new request context for your
+method and execute it inside the context.
 
 ```ts
 @Injectable()
 export class MyService {
-
-  constructor(private readonly orm: MikroORM) { }
+  constructor(private readonly orm: MikroORM) {}
 
   @UseRequestContext()
   async doSomething() {
     // this will be executed in a separate context
   }
-
 }
 ```
 
@@ -281,4 +257,5 @@ export class PhotoModule {}
 ```
 
 #### Example
+
 A real world example of NestJS with MikroORM can be found [here](https://github.com/mikro-orm/nestjs-realworld-example-app)
diff --git a/src/app/homepage/pages/microservices/custom-transport/custom-transport.component.html b/src/app/homepage/pages/microservices/custom-transport/custom-transport.component.html
@@ -193,6 +193,38 @@ <h4 appAnchor id="client-proxy"><span>Client proxy</span></h4>
 connect
 event to dispatch:  &#123; pattern: &#39;event&#39;, data: &#39;Hello world!&#39; &#125;
 </code></pre>
+<h4 appAnchor id="message-serialization"><span>Message serialization</span></h4>
+<p>If you need to add some custom logic around the serialization of responses on the client side, you can use a custom class that extends the <code>ClientProxy</code> class or one of its child classes. For modifying successful requests you can override the <code>serializeResponse</code> method, and for modifying any errors that go through this client you can override the <code>serializeError</code> method. To make use of this custom class, you can pass the class itself to the <code>ClientsModule.register()</code> method using the <code>customClass</code> property. Below is an example of a custom <code>ClientProxy</code> that serializes each error into an <code>RpcException</code>.</p>
+
+<span class="filename">
+  {{ 'error-handling.proxy' | extension: appb95b5d8490d1d2e5a8dfa4408547e4314e16a15a.isJsActive }}
+<app-tabs #appb95b5d8490d1d2e5a8dfa4408547e4314e16a15a></app-tabs>
+</span><pre><code class="language-typescript">
+import &#123; ClientTcp, RpcException &#125; from &#39;@nestjs/microservices&#39;;
+
+class ErrorHandlingProxy extends ClientTCP &#123;
+  serializeError(err: Error) &#123;
+    return new RpcException(err);
+  &#125;
+&#125;
+</code></pre><p>and then use it in the <code>ClientsModule</code> like so:</p>
+
+<span class="filename">
+  {{ 'app.module' | extension: appc6380cff174d3675b3c6660600efaf7aec5d9272.isJsActive }}
+<app-tabs #appc6380cff174d3675b3c6660600efaf7aec5d9272></app-tabs>
+</span><pre><code class="language-typescript">
+@Module(&#123;
+  imports: [
+    ClientsModule.register(&#123;
+      name: &#39;CustomProxy&#39;,
+      customClass: ErrorHandlingProxy,
+    &#125;),
+  ]
+&#125;)
+export class AppModule
+</code></pre><blockquote class="
+info "><strong>hint</strong> This is the class itself being passed to <code>customClass</code>, not an instance of the class. Nest will create the instance under the hood for you, and will pass any options given to the <code>options</code> property to the new <code>ClientProxy</code>.
+</blockquote>
 
 </div>
 
