feat: evaluate the user in the go sdk to improve response latency

[cre8ivejp]

Summary

The current architecture when the get variation interface is called. It requests the evaluation directly from the server.
This approach is more straightforward but may introduce latency. Also, this could lead to infra-cost issues because it could evaluate the same user many times in a short time, even if the flag didn't change.

We should consider implementing the evaluation logic in the SDK to implement a cache similar to the client SDK.
This would improve the latency issues and drastically reduce the requests to the server, reducing the infra-cost.

I was thinking of creating a new common repository for the evaluation and proto files, but it would be better if we kept this as a mono repo for this case. We can move it to another repository in the future if needed.

TODO

• Create the proto dir as a go module
• Move the evaluation code to a go module
• Implement evaluation module in the API Gateway
• Implement server-side API key type (Backend & Frontend)
• Implement API to get all flags and segment users per environment using the server-side API key
• Implement cache in the Go SDK (In-memory)
• Implement the configuration to select to evaluate locally or remotely

API Gateway

It will evaluate the user from the evaluation module. There are no changes in the evaluation code.

API Key

We will implement a new key type, which will have access to all the flags and segment users per environment.
I will add a new column called key_type in the api_key table to check what the key can retrieve.

• Server-side: Access to All flags and segment users per environment (Read-only)
• Client-side: Access to a single user's evaluation (Read-only)

SDK cache

The cacher will cache all the flags and segment users per environment in memory.
It will poll the latest data from the Bucketeer server and override the current in-memory data every 30 seconds.
This implementation will be similar to the other client SDKs.

SDK get variation interface

We won't change the current interfaces. The changes will be made internally to evaluate the user in the SDK, just like the Bucketeer app does on the server side.