# Connect to Weaviate instance WITHOUT grpc

**URL:** <https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180>\
**Category:** Support\
**Created:** [September 17, 2024, 8:40am UTC](https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180 "2024-09-17T08:40:12Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mnkasikci](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mnkasikci](https://forum.weaviate.io/u/mnkasikci)\
**Post date:** [September 17, 2024, 8:40am UTC](https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180/1 "2024-09-17T08:40:12Z")

</div>

I want to connect to my old weaviate instance. However, in its current settings, it doesn’t have a load balancer with grpc configured, so i want to do it without grpc.

I want to connect to it via “weaviate-client”: “^3.1.4”.

Is there a way to tell the client to connect WITHOUT grpc?

I tried doing this:

```auto
          this.client = await weaviate.connectToCustom({
            httpHost: config.weaviate.httpHost,
            httpPort: config.weaviate.httpPort,
            httpSecure: true,
            authCredentials: new weaviate.ApiKey(config.weaviate.apiKey),
          });

```

While it passes the health/live check, i get this error:  
Query call with protocol gRPC failed with message: /weaviate.v1.Weaviate/Search UNKNOWN: extract auth: oidc auth is not configured, please try another auth scheme or set up weaviate with OIDC configured

I can confirm that config.weaviate.apiKey is the correct api key.

---

<div class="post-metadata">

**Author:** ![Dirk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/dirk/32/46_2.png) [@Dirk](https://forum.weaviate.io/u/Dirk)\
**Post date:** [September 17, 2024, 11:26am UTC](https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180/2 "2024-09-17T11:26:26Z")

</div>

Hey, then you need to use the old typescript client (v2). V3 only works with GRPC

---

<div class="post-metadata">

**Author:** ![mnkasikci](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mnkasikci](https://forum.weaviate.io/u/mnkasikci)\
**Post date:** [September 18, 2024, 9:31am UTC](https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180/3 "2024-09-18T09:31:21Z")

</div>

Thank you so much for the clarification.

For me it was not clear whether grpc was mandatory for the client, i thought it _preferred_ grpc over http.

What mislead me was, the fact that `grpcHost` was optional in `ConnectToCustomOptions` and that with the configuration above, it passed the ready & live checks. (I am aware that ready and live checks are for the server, not client. But i said to myself, “if the client can initialize & connect & even do ready checks with this configuration, it should be good to go”.

In this case, wouldn’t it be semantically more correct to make the `grpcHost` parameter in `ConnectToCustomOptions` mandatory? Am i missing something? I’d be glad to send a pr for this. Moreover, `httpHost` parameter could be mandatory as well.

---

<div class="post-metadata">

**Author:** ![mnkasikci](https://avatars.discourse-cdn.com/v4/letter/m/b19c9b/32.png) [@mnkasikci](https://forum.weaviate.io/u/mnkasikci)\
**Post date:** [September 18, 2024, 9:32am UTC](https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180/4 "2024-09-18T09:32:13Z")

</div>

Another solution would be making a fallback mechanism. I’d be glad to help prepare a pr for that as well, but obviously that’d take more time.

---

<div class="post-metadata">

**Author:** ![Dirk](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.weaviate.io/dirk/32/46_2.png) [@Dirk](https://forum.weaviate.io/u/Dirk)\
**Post date:** [September 19, 2024, 6:19am UTC](https://forum.weaviate.io/t/connect-to-weaviate-instance-without-grpc/4180/5 "2024-09-19T06:19:57Z")

</div>

> [@mnkasikci](#):
>
> For me it was not clear whether grpc was mandatory for the client, i thought it _preferred_ grpc over http.

For v3 GRPC is mandatory and most functionality does not work without it. It is a complete rewrite from v2 and it is not possible to fall back on http/REST/GQL.

I will pass on your feedback to the TS client dev 🙂