Guía rápida de Go

En unos minutos tu servicio en Go evaluará feature flags en el propio proceso — sin salto de red por comprobación, sin latencia en tu ruta de petición, un solo sondeo sirviendo a cada petición que atiende tu proceso.

Cero dependencias en tiempo de ejecución: el bloque require del SDK está vacío, y así se queda.

1. Instala

El SDK vive en un repositorio público en GitHub — instálalo directamente desde ahí, fijado a la versión publicada:

go get github.com/FortressFlag/FortressFlag_SDK_go@v1.0.0

2. La clave de servidor — un secreto de verdad

Este SDK usa una clave de servidor (ffs_…), y es lo contrario de las claves de cliente que llevan los SDK móviles y web: puede descargar tu ruleset completo, reglas de targeting incluidas. Trátala exactamente como una contraseña de base de datos — una variable de entorno o un gestor de secretos, nunca código, nunca un repositorio, nunca un log. Las dos clases de claves, lado a lado.

3. Arranca el cliente

package main

import (
  "context"
  "os"
  "time"

  fortressflag "github.com/FortressFlag/FortressFlag_SDK_go"
)

func main() {
  client, err := fortressflag.New(fortressflag.Configuration{
    Key: os.Getenv("FF_SERVER_KEY"),
  })
  if err != nil {
    // El único sitio en el que el SDK puede dar error: una configuración
    // mal formada, antes de que nada se sirva.
    panic(err)
  }
  defer client.Close()

  startCtx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
  client.Start(startCtx) // bloquea hasta que llega el primer ruleset (o termina el contexto)
  cancel()

  // ... tu servicio se ejecuta; las comprobaciones de flags son ahora llamadas a funciones en memoria.
}

Start nunca devuelve un error fatal — si la primera descarga no puede llegar a tiempo, el cliente sigue intentándolo en segundo plano y quienes te llaman reciben sus valores por defecto mientras tanto.

4. Evalúa un flag

enabled := client.Bool("new-checkout", fortressflag.Context{
  Key:  "user-42", // tu clave de contexto estable: un id de usuario, un id de sesión — tú eliges
  Tags: map[string]string{"cohort": "beta"},
}, false) // el respaldo si el flag es desconocido o nunca se descargó nada

client.String y client.Number funcionan igual. La Key del contexto es sobre lo que reparten los rollouts porcentuales — pasa el mismo identificador de forma consistente y cada usuario obtiene una cohorte estable. Son tus datos: el SDK nunca los valida, almacena ni registra.

Eso es todo — tu servicio está evaluando flags localmente. Un cambio en el panel llega a cada proceso en aproximadamente un minuto.

La evaluación nunca falla

Bool, String y Number siempre responden y nunca hacen panic — un problema con los flags nunca debe tumbar tu servicio. Un proceso reiniciado sirve tus respaldos del punto de llamada hasta que llega su primera descarga (o pon CachePath en la configuración para persistir el último ruleset en un archivo que elijas, y los reinicios se reanudan desde él al instante). Ni siquiera una clave revocada rompe nada: el SDK sigue evaluando con el último ruleset que descargó hasta que le des una clave nueva.

¿Por dónde seguir?

• Cómo llegan los flags a tu app — el plano de servidor, explicado
• Claves — emite, rota y revoca claves ffs_
• Targeting — las reglas que tu servicio está evaluando ahora