In-Depth: Harness Feature Flags Relay Proxy
Tags: featureflags, relayproxy, go, caching
Published: 2022-02-25 06:10:04

---
title: In-Depth: Harness Feature Flags Relay Proxy
published: true
date: 2022-02-21 14:00:00 UTC
tags: FeatureFlags,RelayProxy,GoLang,Caching 
canonical_url: https://harness.io/blog/in-depth-feature-flags-relay-proxy/
---

The Relay Proxy is a lightweight Go application that runs within your infrastructure and handles all streaming connections to the Harness platform. It fetches all of your flag, target, and target group data on startup, caches it, fetches any updates over time, and serves it to your connected downstream SDKs.

Rather than every client/server connecting directly to the Harness platform and streaming changes, they will connect directly to your installed proxy to receive any flag updates. The proxy can support connecting to multiple environments across different projects for your account, making it a 1:1 replacement for a direct connection. 

## Architecture

### Standard Deployment 

Connecting directly to Harness without installing a proxy is the default option that most customers will use. 

All SDKs connect directly to the Harness platform. For servers in your infrastructure, this means allowing an outbound connection for each, customers consuming a client SDK (e.g. via a mobile app) will fetch their flags from Harness. 

![Standard Deployment](https://blog.harness.io/wp-content/uploads/2022/02/Standard-Deployment.png)

### Proxy Deployment

All SDKs will fetch flags from your internally deployed proxy server. Only this proxy server needs to communicate outbound with Harness. Server SDKs in your infrastructure don’t need any outbound connections. Client SDKs will need to be allowed to access the proxy by your network’s firewall rules.

![Deployment With Relay Proxy](https://blog.harness.io/wp-content/uploads/2022/02/Deployment-With-Proxy-Relay.png)

## Should I Use it?

The proxy is available to help specific use cases. It may not be suitable for smaller customers or all configurations. You should have a valuable use case in mind that you wish to solve, otherwise you may be better off starting your journey with the standard connection model. 

Here are some of the advantages (among others) that may prove worthwhile in your setup:

1. Reduced Network Traffic/Connections

With the standard configuration, each SDK instance you run will reach out to the Harness platform to fetch all the initial flag data, then maintain a streaming connection to receive any updates you make to that environment. 

Depending on your architecture, this could mean tens, hundreds, or even thousands of servers in your network, each maintaining an outbound connection and receiving updates for the exact same data. It also requires each server to be capable of contacting the outside world, which may not be feasible in your setup for configuration or security reasons. 

Using the proxy, you only need a single server to connect to Harness, with all the SDK traffic remaining completely internal to your own data centre. 

1. Clients Don’t Need to Whitelist Harness

If you have customers running client SDKs who have very tight security requirements, they may not allow your app to open third party connections. 

The proxy can resolve this issue by running inside your own environment and piggybacking on any existing whitelist rules your services belong to. 

1. High Availability

For the majority of our customers, the standard Feature Flags configuration has plenty of safeguards to maintain all the availability they’ll ever need. These include:

- [High uptime](https://status.harness.io/);
- Client/Server SDKs caching values in case connection is lost;
- Server SDKs store values to disk in case they restart with no available connection;
- Ability to define sensible defaults in the worst case scenario of starting up with no cache or connection.

If, however, you require more than this (or have a mandate to reduce external dependencies), installing a relay proxy could be ideal. The proxy caches all flag, target, and target group data for all your environments. This means if you lose connectivity to the Harness platform due to downtime, firewall issues, or any other reason, all of your existing and newly-started client and server SDKs will continue to be served the most recent data at all times. 

What’s even better is that as soon as the connectivity issue is resolved, the proxy will automatically reconnect to every environment, fetch any updates it missed, and continue to function normally.

## How Much Does it Cost?

There’s no charge above your regular subscription to install and run the proxy.

This said, you will bear all of the operational costs and architectural complexity associated with running this extra server in your environment. This includes hosting, as well as the time involved to set up, configure, monitor, and optimize an extra service. 

This cost benefit will be more attractive to larger or more security conscious customers (government, medical, fintech, etc.) than small enterprises looking to get started with feature flagging.

## Can I Change Later?

Yes. If you’re in any doubt, we’d recommend starting your journey by using the standard deployment, then migrating towards the proxy server if it benefits your use case.

If you decide to install the proxy later in your journey, the only changes needed for your client and server SDKs are purely configuration-based. Instead of communicating with Harness servers, SDKs can communicate with your proxy server instead, all the other functionality you currently rely on stays the same.

As an example, here are the changes needed to migrate a Golang SDK instance to use the proxy.  

```
// communicate with Harness directly
client, err := harness.NewCfClient(sdkKey)
	
// communicate with your proxy server
client, err := harness.NewCfClient(sdkKey, harness.WithURL(MY_PROXY_URL))
```

This doesn’t have to be a big bang migration either. You can feel free to install the proxy and run some clients/servers through it, while the rest communicate with Harness directly, allowing you to roll it out gradually and assess if the benefits are worth the costs for your setup.

## What Caching Options Are Available?

### In Memory

By default, the proxy will cache flag data in memory. This can be useful for a trial period, but it is not recommended for production deployments. The proxy won’t have access to any flag data on restart until a connection has been established with Harness and the first sync is completed. 

### Redis

Redis is supported as a persistent store for your cached data and is the recommended option. When the proxy is restarted, it will immediately have access to the most recent data while it waits on the sync to complete.

## Where Can I Try it Out?

- Sign up for a [Harness Feature Flags trial](https://app.harness.io/auth/#/signup/?module=cf) today. 
- Check out our [proxy documentation](https://ngdocs.harness.io/article/q0kvq8nd2o-relay-proxy) and install instructions.

We’re thrilled you’re looking at leveling up your feature flags game! For more information on how we do feature flags, take a look at how we architected Feature Flags for [performance at scale](https://harness.io/blog/architecting-feature-flags-performance/).

The post [In-Depth: Harness Feature Flags Relay Proxy](https://harness.io/blog/in-depth-feature-flags-relay-proxy/) appeared first on [Harness](https://harness.io/blog).