View Source Multiverses.Http (multiverses_http v0.1.0)
Multiverses suite to enable isolated HTTP communications over multiverse shards
how-to-use
How to Use
in-your-phoenix-endpoint
In your Phoenix endpoint:
defmodule MyAppWeb.Endpoint do
#...
if Mix.env() == :test do
plug Multiverses.Plug
end
#...
endWarning
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
In your test (assuming the Multiverses.Req adapter is used)
- declare that your test shards over the Http multiverses name domain.
- alias
Multiverses.Reqinstead of using theReqmodule.
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
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
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
Other backends
Currently there is support only for the Req client library. If support for
other libraries is desired, please issue a PR. Compilation of library adapters
will be gated on the :http_clients application environment variable, which is
currently set to [Req].
Link to this section 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.
Link to this section 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.