pollin v0.2.1 Pollin

Simple queue implementation for webhooks and event sources. (Pollin package designed for only callbacks and event sourcing for elixir/erlang applications.)

Motivation

Webhook definition from wikipedia: "Webhooks are "user-defined HTTP callbacks". They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URI configured for the webhook."

And a little event sourcing (https://ookami86.github.io/event-sourcing-in-practice/)

  • Events might have state and sub events

  • Webhooks should respond 200 whenever the request gathered from client. You can even skip authentication/authorization and handle the all the request from the queue.

  • Webhook request should processed using a queue engine.

  • Queue engine should support; pop, fetch, update, delete, dump and reset operations.

  • Allowing dynamic queue creation and other CRUD actions on queue.

  • Extendable backends

Installation

If the package can be installed as:

  1. Add pollin to your list of dependencies in mix.exs:

    def deps do
      [{:pollin, "~> 0.1.0"}]
    end
  2. Ensure pollin is started before your application:

    def application do
      [applications: [:pollin]]
    end

Usage

Endpoint Resources

# Add alias to your module (optional)
alias Pollin.Backend.Memory.EndpointWorker
alias Pollin.Resource.Endpoint
  • Create an endpoint
id = "some_id_for_endpoint"
endpoint = %Endpoint{id: id, secret: "some secret", ttl: 900_000, created_at: :os.system_time}
EndpointWorker.create(endpoint)
  • Update an endpoint
id
|> EndpointWorker.find
|> Map.put(:secret, "new secret")
|> EndpointWorker.update
  • Delete an endpoint
EndpointWorker.delete(id)
  • List all endpoints
EndpointWorker.index
  • Find an endpoint
endpoint = EndpointWorker.find(id)

Callbacks Resources(WebHooks / Event Sources)

  • Push a callback resource to an endpoint
CallbackWorker.push(id, %Pollin.Resource.Callback{})
  • Pop a callback from endpoint
callback = CallbackWorker.pop(id)
  • Pop a callback by an exact key from endpoint
callback = CallbackWorker.pop(id, key)
  • Pop list of callbacks from an endpoint queue by given phase, offset and limit
callbacks = CallbackWorker.pop(id, opts)
  • Pop list of callbacks from endpoint queue by given options offset and limit
callbacks = CallbackWorker.pop(id, opts)
  • Pop a callback from endpoint
callback = CallbackWorker.fetch(id)
  • Pop a callback by an exact key from endpoint
callback = CallbackWorker.fetch(id, key)
  • Fetch list of callbacks from an endpoint queue by given phase, offset and limit
callbacks = CallbackWorker.fetch(id, opts)
  • Fetch list of callbacks from endpoint queue by given offset and limit
callbacks = CallbackWorker.fetch(id, opts)
  • Fetch reverse list of callbacks from an endpoint queue by given phase, offset and limit
callbacks = CallbackWorker.fetch(id, opts)
  • Fetch reverse list of callbacks from endpoint queue by given offset and limit
callbacks = CallbackWorker.fetch(id, opts)
  • Count all callbacks of an endpoint
count = CallbackWorker.count(id)
  • Count all callbacks of an endpoint with filter options
count = CallbackWorker.count(id, %{phase: "unprocessed"})
  • Dump all callbacks of an endpoint
callbacks = CallbackWorker.count(id)
  • Reset all callbacks of an endpoint
CallbackWorker.reset(id)
  • Remove a callback
CallbackWorker.delete(id, key)
  • Update phase of a callback
CallbackWorker.update_phase(id, key, phase)

Backends

You can implement your own backend using Pollin.CallbackInterface behaviour.

License

MIT

Link to this section Summary

Functions

Called when an application is started.

Link to this section Functions

Link to this function

start(type, args)

Called when an application is started.

This function is called when an application is started using Application.start/2 (and functions on top of that, such as Application.ensure_started/2). This function should start the top-level process of the application (which should be the top supervisor of the application's supervision tree if the application follows the OTP design principles around supervision).

start_type defines how the application is started:

  • :normal - used if the startup is a normal startup or if the application is distributed and is started on the current node because of a failover from another node and the application specification key :start_phases is :undefined.
  • {:takeover, node} - used if the application is distributed and is started on the current node because of a failover on the node node.
  • {:failover, node} - used if the application is distributed and is started on the current node because of a failover on node node, and the application specification key :start_phases is not :undefined.

start_args are the arguments passed to the application in the :mod specification key (e.g., mod: {MyApp, [:my_args]}).

This function should either return {:ok, pid} or {:ok, pid, state} if startup is successful. pid should be the PID of the top supervisor. state can be an arbitrary term, and if omitted will default to []; if the application is later stopped, state is passed to the stop/1 callback (see the documentation for the c:stop/1 callback for more information).

use Application provides no default implementation for the start/2 callback.

Callback implementation for Application.start/2.