Split request build and perform steps

Currently functions take arguments and ExForce.Config (for authentication), perform the request, and return optionally transformed response.

config = %ExForce.Config{}

{:ok, resp} = ExForce.query(soql, config)
{:ok, resp} = ExForce.describe_sobject("Account", config)

The main drawback of this approach is that all functions need ExForce.Config for authentication.

A way to avoid that is to make a request struct, and use separate general request handler taking the request.

config = %ExForce.Config{}

{:ok, result} = soql |> ExForce.query() |> ExForce.request(config)

stream = soql |> ExForce.query() |> ExForce.stream_query(config)

ex_aws is taking this approach.

There are several way to implement this interface.

Use general-purpose request struct

pros: simple interface
cons: no type information

@spec get_sobject(sobject_id, sobject_name, list) :: Request.t()

@spec request(Request.t()) :: {:ok, any} | {:error, any}

Use different request struct

pros: keep type information for each request type
cons: need to define request types for different response type

@spec get_sobject(sobject_id, sobject_name, list) :: SObjectRequest.t()

@spec request(SObjectRequest.t()) :: {:ok, SObject.t()} | {:error, any}

For example, ExAws uses ExAws.Operation protocol for perform(ops, config) - ref.

Return func

pros: keep type information at function level
cons: hard to instrument the request

@type request_func :: ((config_or_func) -> {:ok, any} | {:error, any})

@spec get_sobject(sobject_id, sobject_name, list) :: ((config_or_func) -> {:ok, SObject.t()} | {:error, any})

@spec request(request_func) :: {:ok, any} | {:error, any}

chulkilee / ex_force