Proxy

When to Use (Problem)

• The problem requires isolation from the actual implementations that fails produce outputs within the given time.
• The problem requires protection from exposing the actual implementation to the externals.
• The problem requires one to standardizes client facing API.

Example Codes (Solution)

Here is an example in Go:

package main

import (

        "fmt"

)

// this the acutal task hidden internally

type task struct {

}

func (t *task) Print(message string) {

        fmt.Println(message)

}

// PrintAPI is a proxy struct facing client

type PrintAPI struct {

        task *task

}

func NewPrintAPI() *PrintAPI {

        return &PrintAPI{

                task: &task{},

        }

}

func (p *PrintAPI) Print(message string) {

        p.task.Print(message)

}

// client side

func main() {

        p := NewPrintAPI()

        p.Print("Hello World")

}

// Output:

Hello World

Notice that on Client side, it only uses the NewPrintAPI. Print and successfully isolated the internal task.Print method. NewPrintAPI acts as a proxy between the client and the internal struct functions.

This is commonly seen on network servers, where functionalities are often proxies using an API server, be it HTTP, RPC, RESTFUL, or custom TCP/UDP protocols.

Expected Outcome (Consequences)

1. Actual isolation achieved between the client and the internal functionalities.
2. Successful asynchronous implementation for expensive / overhead internal executions.
3. Hide sensitive implementations from clients.
4. Standardizes client side interfaces.
5. Introduces a new level of indirection.
6. Extra operational cost (maintaining proxy servers).
7. Add housekeeping tasks.