Monday, April 15, 2024

Streaming Messages to a Go gRPC Server


 

In this post we will demonstrate streaming gRPC messages to a server using Go.


Create proto file

The proto file describes the gRPC service APIs. In this example we create a single API to send stream of persons from the client to the server.


persons.proto

syntax = "proto3";
option go_package = "my.example.com/com/grpctemplates";

service Persons {
rpc StreamPersons(stream Person) returns(ProcessedIndication){

}
}

message Person{
string name = 1;
int32 age = 2;
}

message ProcessedIndication{

}


Generate Go templates

To generate go sources using the proto file, we first install the required tools:

sudo apt install -y protobuf-compiler
protoc --version
go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.2

Next we run the tools to generate the Go templates:

export PATH="$PATH:$(go env GOPATH)/bin"
protoc --go_out=. --go_opt=paths=source_relative \
--go-grpc_out=. --go-grpc_opt=paths=source_relative \
persons.proto

rm -rf grpctemplates
mkdir grpctemplates
mv persons.pb.go grpctemplates/
mv persons_grpc.pb.go grpctemplates/

The Main

In our example we will run both the client and the server in the same process.

package main

import (
"grpcexample/personsclient"
"grpcexample/personsserver"
"time"
)

func main() {
go func() {
time.Sleep(time.Second)
personsclient.RunClient()
}()

personsserver.RunServer()
}


The Server

The server implements an API to get the stream of persons, prints them, and return a complete indication.

package personsserver

import (
"fmt"
"google.golang.org/grpc"
"grpcexample/grpctemplates"
"io"
"log"
"net"
)

type personsServer struct {
grpctemplates.UnimplementedPersonsServer
}

func (s *personsServer) StreamPersons(stream grpctemplates.Persons_StreamPersonsServer) error {
for {
person, err := stream.Recv()
if err == io.EOF {
return stream.SendAndClose(&grpctemplates.ProcessedIndication{})
}
if err != nil {
panic(err)
}

log.Printf("got person %v\n", person.Name)
}
}

func RunServer() {
log.Print("starting gRPC server")
port := 8080
listener, err := net.Listen("tcp", fmt.Sprintf("localhost:%d", port))
if err != nil {
panic(err)
}

persons := personsServer{}
grpcServer := grpc.NewServer()
grpctemplates.RegisterPersonsServer(grpcServer, &persons)

err = grpcServer.Serve(listener)
if err != nil {
panic(err)
}
}

The Client

The client sends a stream of persons to the server, and waits for completion before closing the connection.

package personsclient

import (
"context"
"fmt"
"google.golang.org/grpc"
"google.golang.org/grpc/credentials/insecure"
"grpcexample/grpctemplates"
"log"
)

func RunClient() {
log.Printf("client sending data starting\n")

connection, err := grpc.Dial(
"localhost:8080",
grpc.WithTransportCredentials(insecure.NewCredentials()),
)
if err != nil {
panic(err)
}

defer func() {
err = connection.Close()
if err != nil {
panic(err)
}
}()

client := grpctemplates.NewPersonsClient(connection)
stream, err := client.StreamPersons(context.Background())
if err != nil {
panic(err)
}

for i := range 10 {
person := grpctemplates.Person{
Name: fmt.Sprintf("person %v", i),
Age: int32(i),
}
err = stream.Send(&person)
if err != nil {
panic(err)
}
}
_, err = stream.CloseAndRecv()
if err != nil {
panic(err)
}
log.Printf("client sending data done\n")
}



Monday, April 8, 2024

GraphQL Usage in Go


 


This post includes an example of GraphQL usage in Go. The actual GraphQL implementation is using the graphql-go library.


Some insights I got from this:

  • Implementing code in GraphQL is much more complicated than using REST. We need to re-write the specifications for each usage, and repeat the fields names. It is not build in to the language like GO and simple JSON marshaling.
  • To use mutation drop the root parenthesis in the query. OMG I've spent an hour trying to understand why it is not working.
  • I believe the advantage of GraphQL over REST is dynamic fields selection. Don't know many applications where this matters.
  • Authorization is not full built into GraphQL. I guess this is why we have so many security issues in applications using GraphQL.



package main

import (
"encoding/json"
"fmt"
"github.com/graphql-go/graphql"
)

type dbActor struct {
Name string
BirthYear int
}

var dbActors = []*dbActor{
{
Name: "John Travolta",
BirthYear: 1954,
},
{
Name: "Robert Redford",
BirthYear: 1936,
},
}

func main() {
schema := createSchema()
var query string

query = `
{
list{
name
birthYear
}
}
`
runQuery(schema, query)

query = `
{
actor(name: "Robert Redford"){
birthYear
}
}
`
runQuery(schema, query)

query = `
mutation {
create(name:"Meryl Streep",birthYear:1949){
name
}
}
`
runQuery(schema, query)

query = `
{
list{
name
birthYear
}
}
`
runQuery(schema, query)

}

func runQuery(schema graphql.Schema, query string) {
params := graphql.Params{
Schema: schema,
RequestString: query,
}

result := graphql.Do(params)
if len(result.Errors) > 0 {
panic(fmt.Errorf("failed to execute graphql operation, errors: %+v", result.Errors))
}

jsonData, err := json.MarshalIndent(result, "", " ")
if err != nil {
panic(err)
}

fmt.Printf("\n%s\n", jsonData)
}

func createSchema() graphql.Schema {
schemaActor := graphql.NewObject(graphql.ObjectConfig{
Name: "actor",
Fields: graphql.Fields{
"name": &graphql.Field{
Type: graphql.String,
},
"birthYear": &graphql.Field{
Type: graphql.Int,
},
},
})

schemaQuery := graphql.NewObject(graphql.ObjectConfig{
Name: "QueryRoot",
Fields: graphql.Fields{
"list": &graphql.Field{
Type: graphql.NewList(schemaActor),
Resolve: func(params graphql.ResolveParams) (interface{}, error) {
return dbActors, nil
},
},
"actor": &graphql.Field{
Type: schemaActor,
Args: graphql.FieldConfigArgument{
"name": &graphql.ArgumentConfig{
Type: graphql.String,
},
},
Resolve: func(params graphql.ResolveParams) (interface{}, error) {
name, ok := params.Args["name"].(string)
if !ok {
panic("name argument invalid")
}
for _, actor := range dbActors {
if actor.Name == name {
return actor, nil
}
}
return nil, nil
},
},
},
})

schemaMutation := graphql.NewObject(graphql.ObjectConfig{
Name: "Mutation",
Fields: graphql.Fields{
"create": &graphql.Field{
Type: schemaActor,
Args: graphql.FieldConfigArgument{
"name": &graphql.ArgumentConfig{
Type: graphql.NewNonNull(graphql.String),
},
"birthYear": &graphql.ArgumentConfig{
Type: graphql.NewNonNull(graphql.Int),
},
},
Resolve: func(params graphql.ResolveParams) (interface{}, error) {
name, ok := params.Args["name"].(string)
if !ok {
panic("name argument invalid")
}
birthYear, ok := params.Args["birthYear"].(int)
if !ok {
panic("birthYear argument invalid")
}
actor := dbActor{
Name: name,
BirthYear: birthYear,
}
dbActors = append(dbActors, &actor)
return actor, nil
},
},
},
})

schemaConfig := graphql.SchemaConfig{
Query: schemaQuery,
Mutation: schemaMutation,
}
schema, err := graphql.NewSchema(schemaConfig)
if err != nil {
panic(err)
}
return schema
}





Monday, April 1, 2024

AWS Application Load Balancer Vs. AWS Network Load Balancer



In this post we will review the AWS load balancers types, and investigate the tasks each load balancer is suitable to perform. We will review this as a load balancer serving clients that access services in a kubernetes cluster.


ALB: AWS Application Load Balancer

An ALB is a communication layer 7 creature.

An ALB distributes traffic among multiple kubernetes cluster services' pods. A single ALB can serve multiple services, and by traffic metadata such as host name and path the ALB selects the target service. Once a service is located, the ALB can route the HTTP request directly to the related pod, while distributing the requests between all the pods that are READY for service. Notice that the ALB's health check differs from the health and ready check configured by the pod, and in case it is not the default access to the slash, special ALB configuration should be made.

ALB handles both HTTP 1.x and HTTP 2.x requests, which means that it can also handle gRPC protocol.

ALB can also supply additional layer 7 functions such as authentication and WAF.

NLB: AWS Network Load Balancer

A NLB is a communication layer 4 creature.

A NLB distributes incoming UDP/TCP connections among a single kubernetes cluster service pods. A single NLB can serve only single service.
The incoming connection is proxy to one of the READY service pods. Once the NLB established the TCP connection to the target pod, it will stay connected as long as the client and the pod keep the connection active. The NLB does not inspect the data transferred in the TCP connection, and hence cannot distribute requests to another pod.

Which Should I use?

Let's start with the price: ALB cost is 0.008$ per LCU, while  NLB cost is 0.006$ per LCU.

So ALB costs more, but it has a major advantage: It distributes per request, and not per TCP connection. This is critical in case we have multiple pods, and long lasting client connection.

ALB IP address must be resolved through DNS, while NLB uses a static IP address, hence if we cannot use DNS, we must use NLB.


Hence to choose the appropriate load balancer type:

  • If we must use static IP address - use NLB
  • If we use non HTTP protocol - use NLB
  • If we have single service with single pod - use NLB
  • If we have single service with short lasting client sockets - use NLB
  • For other cases - use ALB