loopholelabs/frpc-go

fRPC-go is a lightweight, fast, and secure RPC framework implemented for Go that uses Frisbee under the hood

fRPC-go

This is the Go implementation of fRPC, a modern RPC framework designed for high performance and stability, that uses the frisbee-go messaging framework under the hood.

This library requires Go1.18 or later.

Important note about releases and stability

This repository generally follows Semantic Versioning. However, this library is currently in Alpha and is still considered experimental. Breaking changes of the library will not trigger a new major release. The same is true for selected other new features explicitly marked as EXPERIMENTAL in the changelog.

Usage and Documentation

Usage instructions and documentation for fRPC is available at https://frpc.io/.

fRPC is still in very early Alpha. There may be bugs in the library that will be fixed as the library matures and usage of fRPC grows. One of the major benefits to fRPC is that reading the generated code is extremely straight forward, making it easy to debug potential issues down the line.

Unsupported Features

fRPC currently does not support the following features, though they are actively being worked on:

• OneOf Message Types

Example Proto3 files can be found here.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/loopholelabs/frpc-go. For more contribution information check out the contribution guide.

License

The Frisbee project is available as open source under the terms of the Apache License, Version 2.0.

Code of Conduct

Everyone interacting in the Frisbee project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the CNCF Code of Conduct.

Project Managed By:

frpc-go's Issues

License is missing

Description of the Issue. Please be as clear as possible.
The license file is missing in repo - can we pls clarify ? thx

Module declares its path as: github.com/loopholelabs/polyglot but was required as: github.com/loopholelabs/polyglot-go

Cmd: protoc --go-frpc_out=. echo.proto

Error file: echo.frpc.go

It is generating the wrong protoc file.

"github.com/loopholelabs/polyglot" works if pasted:

but the error occurs:

Client-side streaming services

Server-side streaming services

Streaming Overrides the SetOnClosed function

If a user wants to use their own SetOnClosed function, they aren't able to when they also want to use the streaming functionality - because streaming uses the SetOnClosed function for itself.

The best solution to this is as follows:

type Server {
       customSetOnClosedFunction func()...
       requiredSetOnClosedFunction func()...
}

func NewServer(...) ... {

  frisbeeServer.SetOnClosed(func(...)... {
     fsrv.requiredSetonClosedFunction(...)
     if fsrv.customSetonClosedFunction != nil {
         fsrv.customSetOnClosed(...)
     } 
  }

}

You'll then also have to override the server.SetOnClosed function to that it modifies the customSetOnClosedFunction variable

Linter fails on `connectionContextKey` being an int

The standard Go linter fails on the connectionContextKey being an int.

 ERROR: should not use built-in type string as key for value; define your own type to avoid collisions (SA1029)

Suggest defining a context key to prevent error on other projects:

type contextKey int

const connectionContextKey contextKey = 1000

Language support beyond go / TS / rust?

What is the plan for language support beyond go / TS / rust? Would be nice to have a clear roadmap for ETA of python, ruby, elixir, java, etc.

Add schema to buf registry

Buf is a handy tool for generating code from .proto files. You can specify remote plugins using the buf schema registry, found here: https://buf.build/plugins

I believe there's an alternative solution where I can point buf to a local binary (your install), but it would be nice if the schema registry approach could also work.

Streaming services

CloseErrors should cause fRPC to Close the underlying connection

Currently, returning an error from an fRPC handler does not close the underlying connection. This default behaviour is fine.

However, users should be able to return a special CloseError type - which will close the underlying connection once the error has been written.

An example implementation the CloseError

type CloseError struct {
	err error
}

func NewCloseError(err error) CloseError {
	return CloseError{err: err}
}

func (e CloseError) Error() string {
	return e.err.Error()
}

And in the generated fRPC Code, an example check:

table[10] = func(ctx context.Context, incoming *packet.Packet) (outgoing *packet.Packet, action frisbee.Action) {
		req := NewProxyRequest()
		err := req.Decode((*incoming.Content)[:incoming.Metadata.ContentLength])
		if err == nil {
			if req.ignore {
				controller.Proxy(ctx, req)
			} else {
				var res *ProxyResponse
				outgoing = incoming
				outgoing.Content.Reset()
				res, err = controller.Proxy(ctx, req)
				if err != nil {
					if _, ok := err.(CloseError); ok {
						action = frisbee.CLOSE
					}
					res.Error(outgoing.Content, err)
				} else {
					res.Encode(outgoing.Content)
				}
				outgoing.Metadata.ContentLength = uint32(len(*outgoing.Content))
			}
		}
		return
	}

How to use windows client?

How to use windows client?
Can the Frpc-go windows client directly use Frpc's Frpc.exe and Frcp.toml?

Linter fails on generated `NilDecode` error

Acceptance Criteria

• gofmt passes without warnings
• A Github Action runs gofmt on push to verify generated code

Other Notes

Generated code currently fails the gofmt lint check due to not conforming to error naming conventions

Bi-directional streaming services

Add connect-go, drpc benchmarks

Hi! Just found the project researching benchmarks between the most popular frameworks like connect-go, twirp, drpc and grpc of course.

I think by adding benchmarks against these frameworks you will be able to attract more users taking into account the fact that frpc is positioned as a fast framework.

Didn't try frpc yet but sure I will! Thank you for you hard work!

Rust Polyglot support for encoding to a byte array in the stack

RPC Methods Cannot Have the Same Name

When we create the following proto file:

service MyService {
  rpc MyMethod(MyRequest) returns (MyResponse) {}
}

service MyOtherService {
  rpc MyMethod(MyRequest) returns (MyResponse) {}
}

This is a completely valid proto3 file, however we always coalesce the RPC Services into a single service on the client-side. Because of this (and because the names of the Methods are the same), our generated client ends up with the same method being created for it:

This is bad, and the easiest way around this is to create "subclients":

c := NewClient()
c.MyOtherService.MyMethod()
c.MyService.MyMethod()

Just an empty struct should be fine for this.