Cuando pensamos en Elm, normalmente pensamos en frontend.
Elm fue diseñado para construir interfaces web y tiene algunas características que lo hacen particularmente interesante para eso: tipado estático, programación funcional, ausencia de excepciones en tiempo de ejecución y un modelo de arquitectura bastante simple.
Pero... ¿podemos usar Elm para escribir un servidor?
La respuesta es: sí!
El proyecto Elm Simple Server muestra justamente cómo hacerlo.
El truco está en utilizar Platform.worker.
Un worker permite ejecutar un programa Elm sin interfaz gráfica, procesando mensajes y ejecutando comandos.
La arquitectura es aproximadamente:
HTTP Request
│
▼
Node.js
│
│ port
▼
Elm
│
│ port
▼
Node.js
│
▼
HTTP Response
Es decir, Node.js se encarga del servidor HTTP y Elm de la lógica de la aplicación.
Esto es bastante parecido a utilizar Elm como un motor de procesamiento detrás de Node.
El proyecto propone una API muy sencilla:
main : Server
main =
Server.serve <| \req ->
case req.method of
"GET" ->
case req.url of
"/" ->
ok req Assets.home_elm
"/profile" ->
ok req Assets.profile_elm
"/signup" ->
ok req Assets.signUp_elm
"/login" ->
ok req Assets.login_elm
"/logout" ->
redirect [ clearCookie ] "/"
_ ->
notFound
"POST" ->
Resolver.succeed (Server.proxy "localhost" 9000)
_ ->
notFound_
La idea resulta bastante natural en Elm: un servidor es una función que transforma un Request en una respuesta.
De hecho, el proyecto define:
type Server
serve : (Request -> Resolver Response) -> Server
Y un request es simplemente información:
type alias Request =
{ method : String
, url : String
, headers : Dict String String
, body : Maybe Body
}
No tenemos objetos, excepciones ni un framework gigantesco.
Tenemos datos + funciones + tipos.
Las respuestas también están modeladas como tipos:
empty : Int -> List Header -> Response
string : Int -> List Header -> String -> Response
file : Int -> List Header -> File -> Response
proxy : String -> Int -> Response
Por ejemplo, conceptualmente podríamos construir una respuesta HTTP de esta manera:
string 200
[ header "Content-Type" "text/plain" ]
"Hola desde Elm"
La infraestructura HTTP sigue estando fuera de Elm, pero la lógica que decide qué responder está escrita en Elm.
¿Y las operaciones asíncronas?
Acá aparece Resolver.
El proyecto define:
type Resolver a
succeed : a -> Resolver a
fail : Resolver a -> Resolver a
andThen : (a -> Resolver b)
-> Resolver a
-> Resolver b
Además permite realizar requests HTTP y consultas a Acadia.
La idea es mantener los efectos controlados y bastante alineados con el modelo de Elm.
Por ejemplo:
query : Transaction a -> Resolver (Maybe a)
Esto permite que un servidor Elm pueda consultar datos sin convertir Elm en un lenguaje lleno de primitivas de I/O.
Para mí, lo más interesante del proyecto no es tener "un servidor escrito en Elm".
Es la pregunta que hay detrás: ¿Cuánto de un backend realmente necesita acceso directo a la infraestructura?
Si podemos modelar gran parte de nuestra aplicación como funciones puras sobre datos fuertemente tipados, podemos dejar que otra tecnología se encargue de las partes más "sucias":
Ese es precisamente el enfoque que explora el proyecto junto con Acadia: intentar mantener la mayor cantidad posible de código dentro de un "camino rápido" con tipos y garantías fuertes, y utilizar otros lenguajes cuando realmente haga falta.
¿Es un servidor Elm de producción?
No. El propio repositorio lo presenta como un prototipo y una exploración de diseño. Actualmente la implementación utiliza Elm 0.19.2, Node.js y Acadia 0.3.1.
Pero como experimento es interesante porque demuestra algo que muchas veces olvidamos:
Elm no necesita ser exclusivamente UI.
Platform.worker existe desde hace años y permite ejecutar programas Elm sin DOM. El proyecto simplemente lleva esa capacidad un paso más allá y la utiliza para implementar la lógica de un servidor.
Y ahí aparece una idea bastante linda:
Frontend Elm
│
▼
Backend Elm
│
▼
Database
Con el mismo lenguaje y, sobre todo, con la misma filosofía de tipos, datos inmutables y efectos controlados.
No necesariamente es la arquitectura que usaría para cualquier aplicación.
Pero como experimento de hasta dónde podemos llevar Elm, es realmente interesante.
Dejo link:
No hay comentarios.:
Publicar un comentario