Elixir per idioti /8, costruiamo una API REST super semplice

È un sacco di tempo che non parliamo di Elixir, e il nostro percorso era rimasto un po’ appeso con la parte 7, dove avevamo creato un’applicazioncina di prova con Phoenix Framework. Se vogliamo fare cose più complicate come modellare un microservizio tutto nostro attorno a un dominio ben preciso però qualcosa come quello che abbiamo visto è limitante, perché visualizzare delle paginette web limita un pochino l’interoperabilità che possiamo avere con altri servizi.

E se al posto di pagine web volessimo servire dei JSON in puro stile API REST-ful¹?

Elixir e Phoenix coprono anche questo caso d’uso in maniera eccellente. In realtà potremmo fare il tutto anche senza Phoenix solo usando il webserver che ne è alla base, cioè Cowboy, ma Phoenix offre una serie di semplificazioni “on top” che ci rendono leggermente più semplice la vita, accorciano in maniera notevole questo tutorial, e risultano anche comode per evoluzioni future della nostra piccola API, come il supporto out-of-the-box a JWT².

Bando alle ciance, andiamo a creare il nostro nuovo progettino:

$ mix new tiny_echo_api --no-webpack --no-ecto

Usando lo scaffolder di Phoenix, che è fatto molto bene, andiamo a dichiarare che stiamo creando un nuovo progetto senza bisogno di frontend (--no-webpack) e senza strato di persistenza su database (--no-ecto)³.

Spostiamoci nella directory che è stata appena creata, installiamo le dipendenze del nostro progetto e facciamolo partire:

$ cd tiny_api
$ mix deps.get
$ mix phx.server

localhost:4000 ci mostrerà la solita paginetta di benvenuto, non diamole troppa attenzione, e andiamo immediatamente a implementare un nuovo endpoint che prende in input una stringa, e ce la restituisce dentro un JSON. Non un grande servizio in sé, ma è un ottimo modo per fare tutto il giro, vedere cosa ci mette a dispozione Phoenix e eventualmente cominciare a costruirci sopra qualcosa.

Apriamo il router, che abbiamo già visto nell’episodio precedente:

# lib/tiny_api_web/router.ex

defmodule TinyApiWeb.Router do
  use TinyApiWeb, :router

  pipeline :browser do
    plug :accepts, ["html"]
    plug :fetch_session
    plug :fetch_flash
    plug :protect_from_forgery
    plug :put_secure_browser_headers
  end

  pipeline :api do
    plug :accepts, ["json"]
  end

  scope "/", TinyApiWeb do
    pipe_through :browser

    get "/", PageController, :index
  end

  # Other scopes may use custom stacks.
  # scope "/api", TinyApiWeb do
  #   pipe_through :api
  # end

  # Enables LiveDashboard only for development
  #
  # If you want to use the LiveDashboard in production, you should put
  # it behind authentication and allow only admins to access it.
  # If your application does not have an admins-only section yet,
  # you can use Plug.BasicAuth to set up some basic authentication
  # as long as you are also using SSL (which you should anyway).
  if Mix.env() in [:dev, :test] do
    import Phoenix.LiveDashboard.Router

    scope "/" do
      pipe_through :browser
      live_dashboard "/dashboard", metrics: TinyApiWeb.Telemetry
    end
  end
end

E andiamo a modificare le rotte dichiarate in questo modo:

scope "/", TinyApiWeb do
  pipe_through :browser

  get "/", PageController, :index
  get "/echo/:payload", EchoController, :echo
end

In questo modo andiamo a dichiarare una nuova rotta disponibile solo in GET che ha la forma /echo/qualcosa, e andremo poi a fare in modo che quando noi chiamiamo la nostra applicazione sulla rotta /echo/qualcosa quella ci risponda a sua volta qualcosa dentro un JSON di risposta.

Nel router abbiamo dichiarato che andremo a pescare la funzione echo da un controller chiamato EchoController; Phoenix si aspetterà il modulo corrispondente, quindi andiamolo a creare, mettendoci dentro anche l’implementazione della funzione echo:

# lib/tiny_api_web/controllers/echo_controller.ex

defmodule TinyApiWeb.EchoController do
  @moduledoc """
  This module handles echo requests and replies back
  with an echo JSON containing the word used by the request.
  """

  use TinyApiWeb, :controller

  def echo(conn, params) do
    response = %{"reply" => params["payload"]}
    json(conn, response)
  end
end

Eccoci qua: come vediamo abbiamo definito il modulo TinyApiWeb.EchoController, ci abbiamo messo addirittura una bellissima @moduledoc per aiutare chi si imbatte in questo modulo a capire che cosa fa (Elixir dispone di utility che generano automaticamente la documentazione corrispondente da queste annotazioni), gli abbiamo detto di comportarsi come un controller Phoenix attraverso l’uso di use, e abbiamo implementato la funzione echo, che va poi a rispondere usando la funzione json messaci a disposizione da Phoenix per poter rispondere direttamente usando la mappa che abbiamo dichiarato.

Facciamo ripartire il servizio con mix phx.server e andiamo a vedere su http://localhost:4000/echo/this-is-an-answer che cosa abbiamo combinato:

$ curl localhost:4000/echo/this-is-an-answer
{"reply":"this-is-an-answer"}

Bonus trick: usare la destrutturazione

Volendo sfruttare la potenza della sintassi di Elixir, possiamo implementare la funzione echo in un altro modo, andando a usare la destrutturazione per tirare fuori il campo payload dai parametri della chiamata poi poi andare a costruire la mappa con la risposta direttamente inline:

def echo(conn, params) do
  %{"payload" => payload} = params
  json(conn, %{"reply" => payload})
end

Oppure, volendo essere più concisi, andando a sfruttare tutto quello che la sintassi di Elixir ci mette a disposizione, così da scrivere tutto su una sola riga:

def echo(conn, %{"payload" => payload}), do: json(conn, %{"reply" => payload})

A voi giudicare se in questo modo si perde di leggibilità. Quello che andiamo a fare in questo modo è utilizzare il pattern matching insieme alla destrutturazione direttamente nella firma della funzione. Le tre implementazioni che abbiamo visto sono assolutamente equivalenti.

Volete implementare un nuovo endpoint nel vostro servizio? Adesso avete visto come funziona tutto il giro. Potete sbizzarrirvi: fatelo! :-)

Elixir, programmazione funzionale e tanto ridere, live con Francesco Sciuti

Ultimamente sembro uno di quei tizi stile late nineties che non scrivevano mai sul blog e quando scrivevano finivano per scrivere una cosa tipo “non scrivo da un botto di tempo, ma tornerò”, poi non tornavano. Vorrei scrivere la stessa cosa, e vorrei garantire che non finirò come quei tizi, ma mi rendo conto che solo un track record positivo potrà confermare nel futuro che questa speranza non è stata disattesa.

A parte le farneticazioni da festa d’addio di Bilbo Baggins, sono stato ospite di una live di Francesco Sciuti in cui blateravo di Elixir e di programmazione funzionale: se è vero che chi sa fa e chi non sa insegna, effettivamente questo fa il paio col fatto che io non mi ritenga particolarmente qualificato per parlare di entrambe queste cose.

Eppure ci siamo divertiti un sacco! E ho avuto anche l’opportunità di raccontare alcuni aneddoti relativi alla mia vita universitaria, a quando ho iniziato a sviluppare, a spiegare un paio di concetti che ho assimilato durante gli anni e a mettere in luce alcune delle particolarità che rendono Elixir un ottimo linguaggio e un’ottima piattaforma per costruire applicazioni stateful e/o che fanno largo uso di concorrenza.

Francesco è veramente un grande, mi sono avvicinato al canale di Devmy da poco, e ho scoperto che tanti amici hanno già parlato da lui con argomenti super interessanti, per cui vi raccomando di guardare tutti (per quanto possibile) i video con attenzione, dato che gli speaker sono di calibro eccezion fatta per il sottoscritto :-D

Oltre lo sviluppo software, io e Francesco abbiamo altri punti di contatto: lui è un capellone e io sono un ex capellone¹, lui è un metallaro e io sono un metallaro, lui è un imbecille (nel senso buono del termine) e io anche (nel senso meno buono del termine).

Insomma, date le premesse sfavillanti, è stata un’esperienza meravigliosa che spero di ripetere a breve, comprensiva di micro-live-coding per spiegare multimethod e currying. Yeah!

Gitbar episodio 44: due chiacchiere sull'open source, CouchDB e Elixir con Mauro Murru

Con grandissimo senso di colpa posto solo adesso una intervista che mi ha visto ospite, purtroppo è un periodo molto complicato a livello di progetti, tant’è che spero di condividerne sempre qualcuno su questo mio taccuino, e invece per sapere che sto facendo uno fa prima a prendersi un appuntamento su Google Calendar come abbiamo dovuto fare io e Mauro per questa sua puntata di Gitbar, il podcast per i software developer italofoni, in cui infatti ci sono molto più cose sui miei ultimi progetti che su questo stesso blog :-D

Innanzi tutto le cose importanti: il tema di questo episodio di Gitbar, in cui il buon Mauro “@brainrepo” Murru mi ha intervistato per una buona ora e mezza, è Elixir, insieme a una bella panoramica di CouchDB e alla discussione sull’importanza dell’open source per uno sviluppatore, sia come opportunità di crescita che ci consolidamento della maggior parte delle competenze – sia hard skill che soft skill.

Potete ascoltare l’episodio online, e andare su gitbar.it per altre perle ma soprattutto per i riferimenti al gruppo Telegram e per sapere in generale come entrare in contatto con la community.

Da parte mia non solo devo ringraziare Mauro per l’ospitalità¹, ma devo anche fargli i complimenti per la preparazione: la discussione sul pattern matching mi ha colto un filo impreparato perché di solito non mi trovo a dover rispiegare il concetto a qualcuno che già lo sa, e soprattutto non mi era mai capitato di parlare in “diretta radiofonica” con qualcuno che avesse una conoscenza così profonda di come si può usare il multi-master sync di CouchDB.

Sono molto felice del risultato: con un intervistatore così e un output del genere, spero che l’esperienza si ripeta!

Photo courtesy of Torsten Dettlaf

L'open source ci rende sviluppatori migliori: il panel di Codemotion il 29 settembre

Per tanto tempo durante le nostre chiacchierate negli orari più improbabili della giornata io e Mattia abbiamo scherzato sulla possibilità di un panel moderato da lui con il sottoscritto come partecipante. “Pensa se succedesse, che casino, hahah”, gli dicevo ingenuamente; poi all’improvviso mi ha scritto che sarebbe successo. Tipo lo scudetto della Roma, che non succede ma se succede.

E quindi il 29 settembre (ovvero questo martedì, dopodomani) saremo io, Leonardo Zizzamia e Matteo Collina, moderati da Mattia Tommasone, riuniti a parlare del perché contribuire a progetti open source renda sviluppatori migliori. La mia tesi di base, piccolo spoiler, è che renda sviluppatori migliori perché di base ci rende persone migliori.

L’orario lo trovate nella pagina dell’evento, a cui per accedere è necessaria l’iscrizione. Probabilmente verrà caricato poi il filmato anche su YouTube, ma è inutile che vi dica che così vi perdereste l’occasione di farmi delle domande imbarazzanti in diretta, o di fare delle domande serie a Matteo, Leonardo e Mattia che sono persone molto più competenti del sottoscritto.

Birba chi manca ;-)

Recensione: Humanless, di Massimo Chiriatti

Ho avuto l’immensa fortuna di conoscere Massimo Chiriatti personalmente, ancor prima che professionalmente, e già da tempo volevo inaugurare una serie di recensioni su questo blog ma non riuscivo mai a trovare il libro adatto; così quando Massimo stesso mi ha scritto per comunicarmi che ne aveva (finalmente) scritto uno suo ho pensato di non potermi esimere. Quindi eccoci qua :-)

Humanless è un libro molto particolare, sarà che l’ho letto conoscendo l’autore, sarà che sono particolarmente preso dai temi che tratta, saranno tante cose, fatto sta che ormai lo sto consigliando a ogni piè sospinto a chi mi chiede “Alessio, ma hai della letteratura critica sull’industria del software?”¹. È un libro particolare perché parla di algoritmi senza contenere nessun algoritmo, ed è un libro particolare perché parla di generazioni di algoritmi: un concetto quasi cyberpunk, espresso da un tecnico, un padre di algoritmi, con un ritmo clamoroso che ti fa crogiolare nel piacere dell’attesa di capitolo in capitolo. Un libro particolare, ai miei occhi, perché parla a un padre di algoritmi col tono tutto sommato di un altro padre di algoritmi. Da creatore a creatore.

E dove stiamo andando?

Sostanzialmente il libro parla di questo, descrive uno status quo if-then-else dove l’algoritmica di base si basava sul confronto singolo, della quale è avvenuta la spaccatura inesorabile, la disruption che tanto piace agli startuppari, attraverso uno strumento su tutti, ovvero quello del machine learning. Massimo ci pone quindi dinanzi alla narrativa di un mondo nuovo, dove agli algoritmi viene fatto un dono adamitico, ovvero quello di affrancarsi almeno in parte dal proprio creatore evolvendo in direzioni mai pensate, tuttavia rispettose dei bias, dei preconcetti che i programmatori stessi infondono alle proprie creature².

Da una parte l’autore invita a riflettere sulle conseguenze nefaste della tecnologia impiegata per gli scopi peggiori e senza un minimo di oculatezza: nonostante l’impronta tecnica, è un libro che parla di caveat, di diseguaglianza sociale, di impoverimento del genere umano.

Dall’altra parte viene messo in evidenza come l’applicazione di un pensiero maggiormente critico a queste tecnologie, a queste ricette, a questi ingredienti delle cucine digitali che sono oggi le workstation dei programmatori possa innescare un circolo virtuoso che ci consenta di reinventare i concetti stessi di società, di famiglia, di lavoro, di azienda, di stato. Tutto questo accompagnando per mano gli algoritmi, che sanno pensare solo a se stessi perché è il loro tratto intrinseco non curarsi di ciò che accade loro attorno. Una inconsueta immagine di un futuro dove piuttosto che soppiantarci, sono le macchine ad aver ancora una volta bisogno del genere umano.

Personalmente, Humanless me lo sono proprio goduto: lentamente assorbito pagina dopo pagina, non è passata una sera che non lo leggessi prima di andare a dormire; e piuttosto che addormentarmi di botto, passare quei buoni dieci minuti nel letto a riflettere su quello che avevo letto, su quanto quello che descrive Massimo si stia già avverando, quanto si sia concretizzato da anni, e quanto ancora ci attende. Una lettura a tratti terrorizzante, a tratti entusiasmante.

Come il futuro.

Potete comprare Humanless di Massimo Chiriatti su Amazon, e venire tracciati da un algoritmo. Oppure potete ordinarlo dal vostro libraio di fiducia: è una pratica un po’ desueta, ma non si sa mai.