View Source Multiverses.Http (multiverses_http v0.4.0)

Multiverses suite to enable isolated HTTP communications over multiverse shards

You may not need this library

If you only use Phoenix.ConnTest to run your integration tests, you may not need this library.

How to Use

In your Phoenix endpoint:

defmodule MyAppWeb.Endpoint do
  #...

  if Mix.env() == :test do
    plug Multiverses.Plug
  end

  #...
end

Warning

If you anticipate needing to recompile the Endpoint module on the fly you will need a better way to store the build environment, as the Mix module may not be available to the running VM.

In your test (assuming the Multiverses.Req adapter is used)

  • declare that your test shards over the Http multiverses name domain.
  • alias Multiverses.Req instead of using the Req module.
defmodule MyAppTest do

  alias Multiverses.Req

  @port #....

  setup do
    Multiverses.shard(Http)
  end

  test "some test" do
    result = Req.get("localhost:#{@port}")
    assert result = #...
  end
end

How it works

The adapters for the http clients inject the Multiverses.shard/1 id into the http header x-multiverse-id. This is then intercepted by the Multiverses.Plug module plug in your Endpoint, which then performs a lookup to obtain the :$callers for the request; this :$callers chain is then added to the request process dictionary for the duration of the http Plug pipeline.

Because this exchange installs :$callers a side effect is that other services that are :$callers aware, such as Mox or Ecto will be able to see their respective checkouts.

Cluster awareness

Multiverses.Http is tested to work over a BEAM cluster.

If you spin up a cluster as a part of your tests, you can issue an http request to a node that is not the node running ExUnit and the :$callers for the request will be remote pids (relative to the request handlers). Before proceeding with clustered tests, check to see if the modules that depend on this (e.g. Mox, Ecto) are able to correctly route their sandbox checkouts to the correct node in the cluster.

Other backends

Currently there is support only for the Req client library. If support for other libraries is desired, please issue a PR.

Summary

Functions

finds the current process' Multiverses shard (Http) id and looks up the associated :$callers chain. This chain is then imported into as the current process' :$callers chain.

Returns a specification to start this module under a supervisor.

Callback implementation for GenServer.init/1.

obtains the Multiverses shard (Http) id and registers the current calling process :$callers stack, if it has not already been registered.

Functions

finds the current process' Multiverses shard (Http) id and looks up the associated :$callers chain. This chain is then imported into as the current process' :$callers chain.

Generally you would only want to call this function if you are writing a non- Plug http handler or a websocket server. In such a case you should call this function immediately after associating the current process with the shard using Multiverses.allow/3 or Multiverses.allow/2.

Returns a specification to start this module under a supervisor.

See Supervisor.

Callback implementation for GenServer.init/1.

obtains the Multiverses shard (Http) id and registers the current calling process :$callers stack, if it has not already been registered.

Generally you would only want to call this function if you are implementing an adapter for an HTTP or websocket client library.