xerions/exd

Name: exd

Owner: xerions

Description: Library for data handling on backend systems, based on Ecto for Elixir and Erlang.

Created: 2015-03-09 12:09:58.0

Updated: 2018-02-21 07:55:31.0

Pushed: 2016-11-09 19:22:44.0

Homepage: null

Size: 182

Language: Elixir

GitHub Committers

UserMost Recent Commit# Commits

Other Committers

UserEmailMost Recent Commit# Commits

README

Exd Build Status Coverage Status

Main goals

Exd - library based on ecto for productive boost in data handling for backend systems. There are some different goals, make it possible to quick bootstrap and migrate, allow configuration-based change of models ( customizing ) and implementing API in generic way.

If some of functionality ( like auto migration ) will be usefull generally in ecto, we are ready to move and contribute it to ecto.

For playing with database and try all examples, use ecto_it.

Development state

Very alpha, functional, some parts are still not working or not working properly.

Configurable model on start

There is model_add construct and a function, which allows on start to define the model and with 'plugins', how should the data see.

rt Exd.Model

l Weather do # is for later at now
hema "weather" do
field :city
field :temp_lo, :integer
field :temp_hi, :integer
field :prcp,    :float, default: 0.0
d

f test1, do: 1
# compiles to Ecto model

l_add WindWeather, to: Weather do
hema do
field :wind, :float, default: 0.0
d
f test2, do: 2

After that it possible to generate the right model on start:

Model.compile(Weather, [WindWeather])
Model.compile(Weather, [])

This functionality may be changed in the future to an explicit composable model.

Export an API

It is possible to export your model in generic way to a consumer.

For example:

odule Weather.Api do
oduledoc "Weather API documentation"
ame "Weather"
ech_name "weather"
e Exd.Api, model: Weather, repo: EctoIt.Repo
ud

Use precompiled API. (Note: to get example work, you need to compile model and API, because for a iex compilation, the documentation is not available)

ENV=test iex -S mix

Now you have many different methods, which is possible to introspect with apix.

 Apix.spec(Weather.Api, :methods)
tions", "post", "put", "get", "delete"]

By using of Exd.Api you will be automatically get method options, which is possible to use to introspect yourself.

 Apix.apply(Weather.Api, "options", %{})

You can describe nested API via apis option in Exd.Api. If you want to use CLI or WEB you should have application's API. This is achieved by adding attribute @app: true to API module.

For example:

odule Example.Api do
oduledoc "Example application"
ame "Example"
ech_name "exd"
pp true
e Exd.Api, apis: [City.Api, Weather.Api]

CLI

Now, you can generate CLI with:

exd.escript

Start named node:

X_ENV=test iex --sname test -S mix
 Application.ensure_all_started(:ecto_it)
 Ecto.Migration.Auto.migrate(EctoIt.Repo, City)
 Ecto.Migration.Auto.migrate(EctoIt.Repo, Weather)
 :code.load_file(City.Api)
 :code.load_file(Weather.Api)

Now you can use CLI for accessing running node as:

d insert exd/weather city:Berlin temp_hi:32 temp_lo:20
d get exd/weather id:1

For more information, see './exd -h'. It is still work in progress, zmtp is not functional, as native formatter is not completly implemented, at the moment.

Data handling patterns

There are some patterns on handling data (like inheritance, for example comment can inherit a user picture for that case, if the user changes the own picture, this specific comment will show old picture), that need to have generic handlers. [WiP]

Expose ecto to erlang application

As the ecto interface is based heavily on macros, and not directly invokable in erlang, there should exists reach erlang API to allow to handle and manipulate Ecto model from erlang application. [WiP]

Metrics

EXD collects some metrics via exometer_core. If you want to report those metrics you have to initialize metrics to each API:

Exd.Metrics.init_metrics(City.Api)

It will collect the following metrics:

* request counter
* request handle times
* object counter

The request metrics are broken down by the method which was used (put, post, delete, update) and by the status of the request (success, error, db_not_available). Further a request counter and handle time metric is initialized at start for all API calls combined.

The handle times metrics are internally generated using histograms. These histograms have a time span of 60s.

The exometer IDs can be viewed in the Exd.Metrics module or just execute :exometer_report.list_metrics([:exd]) after you initialized your API metrics.

Model-driven development

For different APIs, there should be an adaptor, which allows to define the model API in consistent way. There are 2 examples at the moment:

Tests

To run tests, you need to pass environment which depends on the database. For example:

ENV=pg mix test

or

ENV=mysql mix test

This work is supported by the National Institutes of Health's National Center for Advancing Translational Sciences, Grant Number U24TR002306. This work is solely the responsibility of the creators and does not necessarily represent the official views of the National Institutes of Health.