| # Name resolving | |
| This examples shows how `ClientConn` can pick different name resolvers. | |
| ## What is a name resolver | |
| A name resolver can be seen as a `map[service-name][]backend-ip`. It takes a | |
| service name, and returns a list of IPs of the backends. A common used name | |
| resolver is DNS. | |
| In this example, a resolver is created to resolve `resolver.example.grpc.io` to | |
| `localhost:50051`. | |
| ## Try it | |
| ``` | |
| go run server/main.go | |
| ``` | |
| ``` | |
| go run client/main.go | |
| ``` | |
| ## Explanation | |
| The echo server is serving on ":50051". Two clients are created, one is dialing | |
| to `passthrough:///localhost:50051`, while the other is dialing to | |
| `example:///resolver.example.grpc.io`. Both of them can connect the server. | |
| Name resolver is picked based on the `scheme` in the target string. See | |
| https://github.com/grpc/grpc/blob/master/doc/naming.md for the target syntax. | |
| The first client picks the `passthrough` resolver, which takes the input, and | |
| use it as the backend addresses. | |
| The second is connecting to service name `resolver.example.grpc.io`. Without a | |
| proper name resolver, this would fail. In the example it picks the `example` | |
| resolver that we installed. The `example` resolver can handle | |
| `resolver.example.grpc.io` correctly by returning the backend address. So even | |
| though the backend IP is not set when ClientConn is created, the connection will | |
| be created to the correct backend. |