bufbuild / knit-go Goto Github PK

When using the default AllowAll config of rs/cors pkg, it returns wildcard "*" for allowed origins, however, in recent versions of Chrome this is blocked when using credentials, which will return an error like:

Access to fetch at 'http://localhost:8080/ensignia.v1alpha1.EnsigniaService/ListClusters' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.
co

Suggested fix:

Specify a config with AllowOriginFunc: func(string) bool { return true } or pass this through to a backend service to answer the OPTIONS request.

Hi! I maintain gqlgen and I was wondering how hard it would be to adapt knit gateway to act as a GraphQL gateway. (browser -> graphql -> knit -> Connect/gRPC )

There's grpc-graphql-gateway and protoc-gen-graphql (and even old rejoiner) to get from protobuf to graphql, so it seems doable.

One tricky piece is as @jhump mentioned:

from my experience with graphql implementation they handle it internally

That is because graphQL requires a unique id field on every entity. But knit does not require that -- so that it can be used with existing Protobuf schemas and RPCs that do not contain that. So knit has no way of "automagically" correlating results with the input IDs.

Also, it is common in microservice architectures for the main entity to not know about IDs of its relations. Instead, a separate service will contains that other data and also contain the foreign relation knowledge. In the SWAPI example, this would be like the Planet entity not having a list of residents/person IDs. So the way to join in the residents of a planet is to ask the "Person" service for all people with a particular "homeworld" planetID. In this case, the framework (be it knit or graphql) cannot know how to join person to planet because it doesn't know which field to join on (in the example case, joining "person.homeworld_id" to "planet.id").

So, since there's not enough information in the schema alone to "explain" the relations and join criteria to the knit framework, it's up to the resolver.

For some reason after several requests the resolver starts to mix the entities

here is an example where the continentId of the entity does not resolve to the correct continent.id

Response

{
	"1": {
		"code": "ala",
		"continent": {
			"code": "asi",
			"id": "zlH0vmjqZuM1D6QqIHvkY",
			"label": "Asia",
			"system": true
		},
 		"continentId": "iFjjl_yrDUFJhQdM4jT5_",
		"id": "x-rlOCWpz93LwoaPuB5rq",
		"label": "Aland Islands"
	}
}

Proto

message ContinentRelationResponse {
  repeated Result values = 1;
  message Result {
    Continent continent = 1;
  }
}

message CountryRelationRequest {
  repeated Country bases = 1;
}

service CountryRelationsResolver {
  rpc ResolveCountryContinent(CountryRelationRequest) returns (ContinentRelationResponse) {
    option (buf.knit.v1alpha1.relation).name = "continent";
    option idempotency_level = NO_SIDE_EFFECTS;
  }
}

Any guidance on what could the problem be?