multiverse alternatives and similar packages
Based on the "Framework Components" category.
Alternatively, view multiverse alternatives based on common mentions on social networks and blogs.
-
ex_admin
ExAdmin is an auto administration package for Elixir and the Phoenix Framework -
phoenix_html
Phoenix.HTML functions for working with HTML strings and templates -
phoenix_ecto
Phoenix and Ecto integration with support for concurrent acceptance testing -
react_phoenix
Make rendering React.js components in Phoenix easy -
absinthe_plug
Plug support for Absinthe, the GraphQL toolkit for Elixir -
phoenix_live_reload
Provides live-reload functionality for Phoenix -
params
Easy parameters validation/casting with Ecto.Schema, akin to Rails' strong parameters. -
phoenix_pubsub_redis
The Redis PubSub adapter for the Phoenix framework -
dayron
A repository `similar` to Ecto.Repo that maps to an underlying http client, sending requests to an external rest api instead of a database -
rummage_phoenix
Full Phoenix Support for Rummage. It can be used for searching, sorting and paginating collections in phoenix. -
phoenix_token_auth
Token authentication solution for Phoenix. Useful for APIs for e.g. single page apps. -
sentinel
DEPRECATED - Phoenix Authentication library that wraps Guardian for extra functionality -
phx_component_helpers
Extensible Phoenix liveview components, without boilerplate -
plug_rails_cookie_session_store
Rails compatible Plug session store -
filterable
Filtering from incoming params in Elixir/Ecto/Phoenix with easy to use DSL. -
access pass
provides a full user authentication experience for an API. Includes login,logout,register,forgot password, forgot username, confirmation email and all that other good stuff. Includes plug for checking for authenticated users and macro for generating the required routes. -
better_params
Cleaner request parameters in Elixir web applications ๐ -
scrivener_headers
Scrivener pagination with headers and web linking -
phoenix_pubsub_rabbitmq
RabbitMQ adapter for Phoenix's PubSub layer -
plug_checkup
PlugCheckup provides a Plug for adding simple health checks to your app -
plug_rest
REST behaviour and Plug router for hypermedia web applications in Elixir -
Votex
Implements vote / like / follow functionality for Ecto models in Elixir. Inspired from Acts as Votable gem in Ruby on Rails -
trailing_format_plug
An elixir plug to support legacy APIs that use a rails-like trailing format: http://api.dev/resources.json -
phoenix_html_simplified_helpers
Some helpers for phoenix html( truncate, time_ago_in_words, number_with_delimiter, url_for, current_page? ) -
plug_canonical_host
PlugCanonicalHost ensures that all requests are served by a single canonical host.
Learn Elixir in as little as 12 Weeks
Do you think we are missing an alternative of multiverse or a related project?
README
Multiverse
This plug helps to manage multiple API versions based on request and response gateways. This is an awesome practice to hide your backward compatibility. It allows to have your code in a latest possible version, without duplicating controllers or models. We use it in production.
Inspired by Stripe API. Read more at MOVE FAST, DON'T BREAK YOUR API or API versioning.
Goals
- reduce changes required to support multiple API versions;
- provide a way to test and schedule API version releases;
- to have minimum dependencies and low performance hit;
- to be flexible enough for most of projects to adopt it.
Adapters
Multiverse allows you to use a custom adapter which can, for eg.:
- store consumer version upon his first request and re-use it as default each time consumer is using your API, eliminating need of passing version headers for them (a.k.a. version pinning). Change this version when consumer has explicitly set it;
- use other than ISO date version types, eg. incremental counters (
v1
,v2
); - handle malformed versions by responding with JSON errors.
Default adapter works with ISO-8601 date from x-api-version
header (configurable). For malformed versions it would log a warning and fallback to the default date (configured via :default_version
setting):
:first
- apply all gates by default. This option is useful when you integrate Multiverse in existing project and API consumers are not ready to accept latest changes by default;:latest
- user current date as default version. This option is useful when there are no legacy clients or there was no breaking changes before those clients started to send API version.
ISO date adapter allows API clients to use channel name instead of date:
latest
channel would fallback to the current date;edge
channel would disable all changes altogether.
Channels allow you to plan version releases upfront and test them without affecting users,
just set future date for a change and pass it explicitly or use edge
channel to test latest
application version.
Installation
The package (take look at hex.pm) can be installed as:
- Add
multiverse
to your list of dependencies inmix.exs
:
def deps do
[{:multiverse, "~> 2.0.0"}]
end
- Make sure that
multiverse
is available at runtime in your production:
def application do
[applications: [:multiverse]]
end
How to use
- Insert this plug into your API pipeline (in your
router.ex
):
pipeline :api do
plug :accepts, ["json"]
plug :put_secure_browser_headers
plug Multiverse, default_version: :latest
end
- Define module that handles change
defmodule AccountTypeChange do
@behaviour Multiverse.Change
def handle_request(%Plug.Conn{} = conn) do
# Mutate your request here
IO.inspect "AccountTypeChange.handle_request applied to request"
conn
end
def handle_response(%Plug.Conn{} = conn) do
# Mutate your response here
IO.inspect "AccountTypeChange.handle_response applied to response"
conn
end
end
- Enable the change:
pipeline :api do
plug :accepts, ["json"]
plug :put_secure_browser_headers
plug Multiverse,
default_version: :latest,
gates: %{
~D[2016-07-21] => [AccountTypeChange]
}
end
- Send your API requests with
X-API-Version
header with version lower or equal to2016-07-20
.
Overriding version header
You can use any version headers by passing option to Multiverse:
pipeline :api do
plug :accepts, ["json"]
plug :put_secure_browser_headers
plug Multiverse,
default_version: :latest,
version_header: "x-my-version-header",
gates: %{
~D[2016-07-21] => [AccountTypeChange]
}
end
Using custom adapters
You can use your own adapter which implements Multiverse.Adapter
behaviour:
pipeline :api do
plug :accepts, ["json"]
plug :put_secure_browser_headers
plug Multiverse,
default_version: :latest,
adapter: MyApp.SmartMultiverseAdapter,
gates: %{
~D[2016-07-21] => [AccountTypeChange]
}
end
Structuring your tests
Split your tests into versions:
$ ls -l test/acceptance total 0 drwxr-xr-x 2 andrew staff 68 Aug 1 19:23 AccountTypeChange drwxr-xr-x 2 andrew staff 68 Aug 1 19:24 OlderChange
Avoid touching request or response in old tests. Create API gates and matching folder in acceptance tests.
Other things you might want to do
- Store Multiverse configuration in
config.ex
:
use Mix.Config
config :my_app, MyApp.Endpoint,
default_version: :latest,
gates: %{
~D[2016-07-21] => [AccountTypeChange]
}
plug Multiverse, otp_app: :my_app, endpoint: __MODULE__
Generate API documentation from changes
@moduledoc
's.Other awesome stuff. Open an issue and tell me about it! :).
License
See [LICENSE.md](LICENSE.md).
*Note that all licence references and agreements mentioned in the multiverse README section above
are relevant to that project's source code only.