> For the complete documentation index, see [llms.txt](https://notes.lirenxn.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.lirenxn.com/2020/wk-notes-02-18-i18n-grpc.md).

# Wk-notes-02-18-i18n-gRPC

### i18n

**Naive approach:**

Store the list of language `json` files in the widget it self.

**Props:**

Easy for micro-frontend, because the bundle size would be controllable.

**Cons:**

Do not involve CMS, content are tied to release.

**Advance approach**

Use CMS. Like AEM. Store fallback as xml/source code, which can be sent to [translate.com](http://translate.com) to generate defferent language version. And use AEM author to change specific content for different region.

#### gRPC <a href="#grpc" id="grpc"></a>

One of **RPC**,

> gRPC can use **protocol buffers** as both its **Interface Definition Language (IDL)** and as its underlying message interchange format.

**What**

* **A Service:** specify the **methods** that can be called remotely with their parameters and return types.
* **gRPC Server:** implements service interface and handle client calls
* **gRPC Stub in Client:** owns a **gRPC stub**, which provides the same methods(interface) as the remote service. Client call stub methods as if it's a local object/function/method
* Stub talks to Server with proto as connection between Service and Client

**Protocol Buffer**

> Google’s mature open source mechanism for serializing structured data

**Define data structure in .proto:**

```
message Person {
  string name = 1;
  int32 id = 2;
  bool has_ponycopter = 3;
}
```

protocol buffer compiler `protoc` -> `.proto` -> access class(DTO)

**Service definition**

```
service HelloService {
  rpc SayHello (HelloRequest) returns (HelloResponse);
}

message HelloRequest {
  string greeting = 1;
}

message HelloResponse {
  string reply = 1;
}
```