Yes it is! You spend your time and your result looks great and finally we can use results of your work for free. Who wants more?
Of course many thanks to all that made dependencies that we are using in our libraries, but anyway we are doing good work and it’s awesome! 
Eiji
2
ShalokShalom
Eiji
@ShalokShalom: In short it’s for defining apis of all 3rd-party apps, libraries and services.
I created this library to declare unique apis of multiple sources where each implementation could not support some part(s) of that api or is just partially implemented.
Also this library could be used as an alternative when you want to use Bahaviour and Protocol, but you don’t have a data that could be passed to each function - again see REST 3rd-party api services. Sometimes you prefer to write MyImpl.get_all() instead of MyImpl.get_all(%MyEmptyStruct{}) + you can dynamically list all implementations (which is not supported in plain Behaviour).
Another helpful thing is that your implementations are identified by {group, id} (both atoms), so you can group implementations and identify them simply by atom. Imagine that you want to create protocol that declares unique code hosting api for bitbucket, github, gitlab and other services. You could pass empty struct or struct with base url, but why do you need to pass anything when you want simply fetch all issues for github implementation?
1
Eiji
For all interested: I pushed new commit to master (not next rc yet).
This version has support for Phoenix.PubSub. I also updated validation part - they are used before calling or casting server + I added specs for all methods that used cast function. Now they returns: {:ok, server_pid} or {:error, error_struct} instead of :ok.
I’m want to add more things before next release candidate. I plan to release it tomorrow or in Monday.
1
Eiji
Just pushed new change to master. From now each api will use GenServer. Currently there is one async function feature_for/4.
This is introduced, because now you can call each feature asynchronously (using implementation api) or synchronously (using just implementation).
For example after you compile code like it:
def_api MyApi do
@moduledoc "Example api"
@doc "Do something really long"
@spec feature_name(term) :: term
def_feature feature_name(first_argument)
def_impl :my_impl do
def_feature_impl feature_name(first_argument) do
Process.sleep(1000)
"result: " <> to_string(first_argument)
end
end
end
# config for auto load:
use Mix.Config
config :ex_api, apis: %{MyApi => [MyApi.MyImpl]}
you can call feature_name asynchronously like:
# Note: no need to implement error callback if you don't expect and/or want catch errors
MyApi.feature_for({nil, :my_impl}, :feature_name, ["sample"], fn result -> IO.puts result end)
or you can also call it synchronously like:
# Note: if not specified group name is nil by default
{:ok, impl} = ExApi.get_impl(MyApi, {nil, :my_impl})
impl.module.feature_name("sample")
# or using module name:
MyApi.MyImpl.feature_name("sample")
I want to implement two more features (fallback implementation for api if no other implementations are registered and checking feature support, so you can firstly check support and then call feature). I plan to implement them tomorrow.
0
Eiji
I just published second release candidate for ExApi!
ping: @OvermindDL1,
You can find docs here. Please let me know if something is still unclear.
1
OvermindDL1
s/implmentations/implementations/ 
A question, is it suitable for a plugin system like, say, Firestorm forum or so? Where they could setup an ‘api’ with a set of hookpoints, and they call those hooks to have plugins do things like run some code or add something to the display or so? And if so, what would that look like? Say for these use-cases:
- Rendering a post so it calls the hook for that, one of the hooks wants to add a thumbs-up button to the bottom of the post, and another hook wants to take that post and change github links to contain inline content from the github link (so it needs to take the existing template and return a mutated version while all other hooks have their own chances to do the same).
- Hooking into when a post is saved so it can sanitize words or throw an error and another wants to take a post when it is saved so it can scan it for indexing purposes (it needs to take the post content and probably should return a mutated version of it that).
Things like that…
1
Eiji
Ooops, thanks
Firstly, I need to say that I don’t wrote any forums and plug-ins for them, so maybe someone could correct me. Here is one possible solution:
# in your code
import ExApi.Api
def_api Firestorm.Hooks.Api do
@moduledoc "Hooks API for Firestorm forum."
# @doc "Hook description goes here ..."
# @spec first_hook_name(...)
def_feature first_hook_name(arg1, arg2, ...)
# other feature implementations, declare no support or simply don't implement
end
# in plug-in code:
import ExApi.Implementation
def_api_impl Firestorm.Hooks.Api, :overmind_dl1_hooks, OvermindDL1.Firestorm.HooksImplementation do
def_feature_impl first_hook_name(arg1, arg2, ...) do
# hook implementation
end
# other feature definitions
end
# main hooks module:
defmodule Firestorm.Hooks do
alias Firesotrm.Hooks.Api
def call(name, args, finish_callback, failure_callback) when is_atom(name) and is_list(args) and is_function(finish_callback) and is_function(failure_callback) do
func_call = {name, Enum.count(args} # {name, arity}
{:ok, hooks_api_impls} = ExApi.get_impls(Api)
# here `hooks_api_impls` is a map %{group_name => impls}
# you could get hooks for specified group
# or get map values and flatten result
# for example, you want to declare `def core_call(name, args)`
# and fetch impls like: `hooks_api_impls[:firestorm_core]`
choosed_hooks = # ...
for impl <- choosed_hooks, is_supported_hook(impl, func_call) do
# here you could call hook asynchronously like:
{:ok, _pid} = impl.api.feature_for(impl, name, args, &finish_callback/1, &failure_callback/1)
# or synchronously like:
case apply(impl.module, name, args) do
{:ok, result} -> apply(&finish_callback(result))
{:error, error} -> apply(&failure_callback(result))
end
end
end
defp is_supported_hook(impl, func_call) do
{:ok, result} = ExApi.get_feature_support(impl, func_call)
end
end
Of course you need to implement something like Firesotrm.Hooks.Loader.
Hmm, how about that these hooks will use drab library?
Hmm, my idea is to do something like:
defmodule Firestorm.Article do
@moduledoc "Article context"
alias Firestorm.Article.Post
alias Firestorm.{Hooks, Repo}
@doc "Validates, call hooks and saves post data into database"
def save_post(input_data) do
changeset = Post.changeset(input_data)
Hooks.call(:before_save_post, [changeset], &on_before_save_post_finish/1, &on_before_save_post_failure/1)
end
defp on_before_save_post_failure(error) do
# format error and show user, auto-submit bug, or just do nothing :-)
end
defp on_before_save_post_finish(result) do
Repo.insert(result)
end
# other context functions ...
end
I wrote this response quickly so there could be errors/mistakes/typos, but this answer firstly comes to my mind. Let me think what do you think about it.
2
OvermindDL1
Well that looks awesome! That is what I was most curious about, an example I could digest to see how it works (I need to dedicate some time to read your extensive thoughts, I keep getting distracted at work so cannot keep my mind on them long enough for it to soak in ^.^;).
Looks quite cool!
2
ShalokShalom
Hey, thanks for mentioning the Firestorm forum, this will be interesting for a friend of mine ^-^
2