Arquitectura de Componentes Web. Patrones de Acceso a Datos

Javier Vélez Reyes
@javiervelezreye
Javier.velez.reyes@gmail.com
Patrones de Acceso a Datos
Arquitecturas Orientadas a
Componentes Web
Octubre 2016

@javiervelezreye 2
Autor
Licenciado por la UPM desde el año 2001 y doctor en informá<ca por
la UNED desde el año 2009, Javier conjuga sus labores como profesor
e inves<gador con la consultoría y la formación técnica para
empresa. Su línea de trabajo actual se centra en la innovación y
desarrollo de tecnologías para la Web. Además realiza ac<vidades de
evangelización y divulgación en diversas comunidades IT y es
coordinador de varios grupos de ámbito local como NodeJS Madrid o
Madrid JS. Forma parte del programa Polymer Polytechnic Speaker y
es mentor del capítulo de Madrid de Node School.
¿Quién Soy?

javier.velez.reyes@gmail.com
@javiervelezreye
linkedin.com/in/javiervelezreyes
gplus.to/javiervelezreyes
jvelez77
javiervelezreyes
youtube.com/user/javiervelezreyes

Javier Vélez Reyes
@javiervelezreye
1 Introducción
§  Arquitectura de Referencia para Componentes Web
§  Plano Arquitectónico, Plano de Diseño & Plano Tecnológico
§  Arquitectura del Subsistema de Datos
Introducción

@javiervelezreye 4
Introducción
I. Arquitectura de Referencia Para Componentes Web
Una arquitectura de referencia establece orientación
acerca de cómo pueden construirse soluciones orientadas
a componentes Web.
La construcción de soluciones orientadas a
componentes Web es inherentemente más
compleja que otras aproximaciones compe<<vas.

@javiervelezreye 5
Introducción
I. Arquitectura de Referencia Para Componentes Web
Una arquitectura de referencia establece orientación
acerca de cómo pueden construirse soluciones orientadas
a componentes Web.
Data
Session
Oﬄine
Integra<on
Access
Role Based
Channel Based
Context Based
View Control
Paging Rou<ng
Content
Containers
Interac<on
Coopera<on
Coordina<on
Comunica<on
Composi<on
Universal Apps
Performance Security
Monitoring Authe. & Autho. Op<miza<on WC & Resource Management
Layers
No<ﬁca<on
User Based
Channel
Viewers

@javiervelezreye 6
Arquitectos
Introducción
II. La Arquitectura de Referencia en el Paradigma de Componentes Web
Plano Arquitectónico
El modelo arquitectónico expone explícitamente todos los
espacios de problema que pueden aparecer en el marco de
soluciones orientadas a componentes web.
Principios
Mecanismos
ObjeSvos
Vis
Evo
Hom
Ada
Dom
Cmp
Enc
Std
Tmp
Evt
Her
DBin
cic
Data
Session
Oﬄine
Integra0on
Role Based
Channel Based
Context Based
View Control
Paging Rou0ng
Content
Containers
Interac0on
Coopera0on
Coordina0on
Comunica0on
Composi0on
Universal Apps
Monitoring Authe. & Autho. Op0miza0on WC & Resource Management
Layers
No0ﬁca0on
User Based
Channel
Viewers

@javiervelezreye 7
Data
Session
Offline
Integra0on
Role Based
Channel Based
Context Based
View Control
Paging Rou0ng
Content
Containers
Interac0on
Coopera0on
Coordina0on
Comunica0on
Composi0on
Universal Apps
Layers
No0fica0on
User Based
Channel
Viewers
Patrones
Diseñadores
Introducción
Plano de Diseño
El diseño dirigido por patrones es una forma sistemá<ca de
explorar esos espacios para encontrar soluciones de
eficacia probada a problemas recurrentes para contextos
reales.
Principios
Mecanismos
Arquitectos
ObjeSvos
Vis
Evo
Hom
Ada
Dom
Cmp
Enc
Std
Tmp
Evt
Her
DBin
cic

@javiervelezreye 8
Data
Session
Offline
Integra0on
Role Based
Channel Based
Context Based
View Control
Paging Rou0ng
Content
Containers
Interac0on
Coopera0on
Coordina0on
Comunica0on
Composi0on
Universal Apps
Layers
No0fica0on
User Based
Channel
Viewers
Plano Tecnológico
Programadores
Introducción
Plano Tecnológico
La arquitectura proporciona componentes como
materialización de patrones. El contexto arquitectónico fija
el contrato de cada componente.
Principios
Mecanismos
Patrones
Arquitectos
ObjeSvos
Vis
Evo
Hom
Ada
Dom
Cmp
Enc
Std
Tmp
Evt
Her
DBin
cic
Diseñadores

@javiervelezreye 9
Introducción
III. El Subsistema de Acceso a Datos
El Subsistema de datos se posiciona dentro de la capa de
integración. En general los componentes operan con datos
accedidos desde esta capa.
Data
Session
Oﬄine
Integra<on
Channel
Access
Role Based
Channel Based
Context Based
View Control
Paging Rou<ng
Content
Containers
Interac<on
Coopera<on
Coordina<on
Comunica<on
Composi<on
Universal Apps
Monitoring Authe. & Autho. Op<miza<on WC & Resource Management
Layers
No<ﬁca<on
User Based
Viewers

@javiervelezreye 10
Introducción
Dentro de la capa de integración se dis<nguen 4
subsistemas que <enen responsabilidades concomitantes
con la ges<ón de datos de fuentes externas.
Data
Session
Offline
Integra<on
Channel
Cómo se gesGona el
diferimiento de información
de estado entre sesiones de
trabajo
Control de Sesión
Cómo se gesGona el acceso a
fuentes de datos y los flujos
de información asociados
Acceso a Datos
Cómo se gesGona la
información extraída del canal
uGlizado (móvil, broser, etc.)
Control de Canal
Cómo se gesGona el acceso a
a datos en contextos de uso
inestables o con desconexión
Acceso Offline

@javiervelezreye 11
Introducción
Podemos caracterizar el subsistema de acceso a datos a
par<r de 3 propiedades fundamentales, su esencia
asíncrona, su cardinalidad y su direccionalidad.
Asincronía
Cardinalidad 1:1
N:1
1:N
N:M
Direccionalidad
Entrante
Saliente

@javiervelezreye 12
Introducción
Subsistema de Datos
Espacio Asíncrono
Las caracterís<cas de los elementos fronterizos incluidos
en el subsistema de datos hace que ésta opere de acuerdo
a un modelo completamente asíncrono.
Desde la perspecGva declaraGva, el
interacción con el subsistema de
datos se hace de manera asíncrona
ya sea a través de eventos o por
medio de data-binding
Interacción asíncrona
Pese a que las fuentes operan en
modelos síncrono y asíncrono (según
Gpo), su acceso desde front, a través
de AJAX es siempre asíncrono
Acceso asíncrono
Async

@javiervelezreye 13
Introducción
Espacio Asíncrono
en el subsistema de acceso a datos hace que esta opere de
acuerdo a un modelo completamente asíncrono.
Async
Arquitectura Pipes & Filters
Debe establecerse una arquitectura pipes & ﬁlters
que permite operar entre el acceso y la fuente a
través de una cadena de transformaciones
Restricción Arquitectónica #1. Pipes & Filters
Subsistema de Datos

@javiervelezreye 14
Introducción
Espacio Asíncrono
Async
e e e e e
Arquitectura Dirigida por Eventos
Las relaciones composiGvas se establecen de acuerdo a
un modelo de eventos. Cada componente opera
reacGvamente en función de los eventos que le llegan
Restricción Arquitectónica #2. Arquitectura EDA
Subsistema de Datos

@javiervelezreye 15
Introducción
Espacio Asíncrono
Async
e e e e e
Contrato ReacSvo Homogéneo
incoming outgoing
call
event command
data
execute (e)
Los componentes deben comparGr un mismo
contrato que les permita operar dentro de
una arquitectura de mensajes
Restricción Arquitectónica #3.
El componente reacciona
a eventos entrantes
La respuesta es también en
forma de eventos salientes
El método execute procesa
eventos entrantes y genera como
respuesta eventos salientes
El payload de los eventos que provienen del
front se llama comando. El que proviene de las
fuentes se llama dato
Subsistema de Datos

@javiervelezreye 16
Introducción
Espacio Asíncrono
Async
e e e e e
Los componentes deben comparGr un mismo
contrato que les permita operar dentro de
una arquitectura de mensajes
CRUD
REST
Pub Sub
WSocket
data
meta
Data
La arquitectura de pipes & ﬁlters no se ve afectada
por la heterogeneidad de las fuentes ya que ésta
se absorbe en el cuerpo de cada comando
De forma similar los mensajes de datos absorben
todos aquellos metadatos necesarios para
gesGonar la respuesta dentro de la arquitectura
Subsistema de Datos

@javiervelezreye 17
Introducción
Direccionalidad
La direccionalidad se refiere a la dirección que toman los
flujos de datos en la arquitectura Pipes & Filters. Podemos
dis<nguir entre flujos de entrada y de salida.
e e e e e
Command
Los flujos entrantes corresponden a
comandos de lectura / escritura
impulsados desde el front
Flujos entrantes
Los flujos salientes corresponden a
respuestas de datos emiGdas por las
fuentes
Flujos salientes
Data
Flujos Entrantes & Salientes Independientes
Async
Subsistema de Datos

@javiervelezreye 18
Introducción
Direccionalidad
e e e e e
Command
Data
Comunicación Correlada
Async
Dada la independencia entre ﬂujos entrantes
y salientes es frecuente tener que aplicar
técnicas de correlación
Comunicación Correlada
Requiere técnicas
de correlación
Subsistema de Datos
Sincronía Asincronía
Request - Response
Query - Reply
One Way
Request – Async Response
NoSﬁcaSón
Soporte natural en
espacio asíncrono

@javiervelezreye 19
Introducción
Direccionalidad
B A
Comunicación Correlada. Ejemplo #1
e e e e e
AB
Async
Dado el carácter asíncrono de la
respuesta el orden no está garanGzado
y puede ser necesario emparejar cada
dato con su comando por ids
Correlación de Comandos & Datos
Subsistema de Datos

@javiervelezreye 20
Introducción
Direccionalidad
Si la respuesta a un comando se
produce por lotes es necesario correlar
las partes de la secuencia que
consGtuyen la información completa
Correlación de Secuencias
A
Comunicación Correlada. Ejemplo #2
e e e e e
A2A1 A3
Async
Subsistema de Datos

@javiervelezreye 21
Introducción
Cardinalidad
La arquitectura de datos obedece a la necesidad principal
de acomodar el modelo de back al esquema de
modularidad u<lizado en front. Esta transformación marca
la cardinalidad de ﬂujos.
Los datos de back se adaptan al
esquema visual de front y recíproca-
mente lo que provoca mulGplicidad de
ﬂujos
Transformación
Command
C1
C2
Data
D2
D1 Async
Subsistema de Datos

Javier Vélez Reyes
@javiervelezreye
2 Patrones de Diseño
en el Acceso a
Datos
§  Patrones de Acceso & Ac<vación
§  Patrones de Distribución
§  Patrones de Transformación
§  Patrones de Op<mización
§  Patrones de Control
Patrones de Diseño en el Acceso a Datos

@javiervelezreye 23
Subsistema de Acceso a Datos

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
El subsistema de Acceso a Datos se dispone en una serie de
niveles que persiguen ciertos principios construc<vos.
Iremos describiéndolos al presentar cada nivel.

@javiervelezreye 24
I. Patrones de Acceso

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
Las caracterísGcas parGculares de acceso a los
disGntos Gpos de fuentes de datos deberían ser
transparentes al desarrollador
Nivel de Acceso

@javiervelezreye 25

Se requiere conectar a una fuente de datos en REST. La conexión
se hace a través de una solicitud AJAX lo que convierte las
llamadas en asíncronas.
El componente wc-rest proporciona un acceso
declara<vo a las llamadas en REST. El contrato
permite operar a cualquiera de los 4 niveles
del protocolo [1].
Fuente REST
<wc-rest
base="http://server"
path="users/[[user]]"
body=[[data]]
action="[[task]]"
header="[[hds]]">
</wc-rest>
La conﬁguración paramétrica se puede
hacer por data-binding. Después solo
resta ejecutar la acción
Primero se proporcionan los parámetros por
data-binding que conﬁguran la llamada y
después se ejecuta el comando.
get()
post()
put()
delete()
data
Cuando la fuente dispone de datos
los emite como un evento de datos,
en alineamiento con la arquitectura
El contrato funcional permite
atacar, en forma de métodos, a la
fuente de datos en back
wc-rest
[1]. Richardson Madurity Model - heps://goo.gl/aYlT

@javiervelezreye 26

Se requiere conectar a una fuente de datos con comunicación
bidireccional y asíncrona entre cliente y servidor. Para ello se
dispone de un servidor que soporta web sockets.
El componente wc-web-socket abre una canal
de comunicación bidireccional con el servidor.
La comunicación para lectura y escritura se
soporta por eventos.
Fuente Web Socket
<wc-socket
base="http://server"
protocol="soap"
channel="[[ch]]"
data="[[data]]">
<wc-rule channel="ch1"/>
</wc-socket>
La conﬁguración de envío reside en los
parámetros (channel) y (data). La de
recepción en los hijos light DOM
Primero se proporcionan los parámetros por
data-binding y después se ejecuta el comando.
En este caso el componente no soporta el
modo auto.
send()
receive()
data
Cuando por alguno de los canales
registrados llegan datos, el
componente emite un evento de
datos
Los métodos send & receive
permiten ejecutar el envío y
escucha de datos
wc-socket

@javiervelezreye 27

Se requiere homogeneizar el acceso a fuentes de datos de
manera que todas presenten el mismo contrato indepen-
dientemente de su protocolo.
El componente wc-data-source ofrece una
adaptación homogénea a cualquier fuente. El
contrato está basado en la escucha recep<va
de comandos.
Adaptador Data Source
<wc-data-source
source="#ds"
type="wc-rest">
<wc-rule from="command.uri" to="uri"/>
<wc-rule from="command.data" to="body"/>
...
</wc-data-source>
Las reglas de conﬁguración establecen, en
este caso, cómo se traduce el comando
entrante al contrato especíﬁco de la
fuente
El componente recibe la fuente contra la que
opera (source) y el <po de fuente (type) para
saber cómo proceder.
command
Este es un evento de entrada. Es
decir, un comando que con<ene
una pe<ción enviada desde el front
en formato JSON
wc-rest
wc-web-socket
wc-data-source
Por detrás el componente Web
sabe mapear al contrato de cada
fuente y operar con él
wc-session
wc-kase
wc-meteor

@javiervelezreye 28
II. Patrones de AcSvación

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
La selección de una fuente de datos y su
acGvación para su posterior uso debería ser
una tarea transparente al desarrollador
Nivel de AcSvación

@javiervelezreye 29

Algunas fuentes de datos requieren de cierta lógica de ac<vación
desde el front en la fase de arranque y cierta lógica de
desac<vación en la fase de liberación.
El componente wc-source-ac<vator se encarga
de lanzar una request a algún servicio en back
encargado de ejecutar lógica de ac<vación y
liberación de fuentes y servicios de datos.
AcSvador de Fuente
<wc-source-activator source="#ds">
<wc-rule on="start" do="[[cmd1]]"/>
<wc-rule on="stop" do="[[cmd2]]"/>
</wc-data-source>
Las reglas deﬁnen un ciclo de vida dinámico. Los métodos
del componente para ese ciclo de vida se crean en
caliente. En este ejemplo usamos la conﬁguración de
ciclo de vida más habitual con métodos (start) y (stop).
El componente recibe la fuente contra la que
opera (source) y el <po de fuente (type) para
saber cómo proceder.
Cierto componente usa el ac<vador
para avisar al back de que va usarse
una fuente de datos
wc-source-acSvator
start()
stop()
start
request
start
[acGvated]
wc-cliente
Un uso par<cular es el
servicio de login / logout

@javiervelezreye 30

Se u<lizan discrecionalmente varias fuentes de datos de diverso
<po y con diversas configuraciones en función de las condiciones
ambientales en las que se realiza el acceso.
El componente wc-source-provider organiza
por claves diferentes <pos de fuentes con
configuraciones específicas y las entrega al
cliente.
Proveedor de Fuentes
<wc-source-provider>
<wc-rule key="users" source="#ds1"/>
<wc-rule key="prods" source="[[ds2]]"/>
...
</wc-source-provider>
El uso de data-binding sobre el parámetro
(source) permite ges<onar dinámicamente la
configuración de este componente
El proveedor es un registro de fuentes que se
recuperan por claves. Las reglas refieren a
fuentes definidas en otros puntos del código.
Cierto componente usa el proveedor
para obtener una fuente de datos
por clave
wc-data-source
wc-source-provider
La comunicación en este caso no es
por eventos sino por mensajes
get
get(k)
wc-cliente

@javiervelezreye 31

Se trabaja con dis<ntas configuraciones de fuentes de datos de
forma temporal. Instanciar un componente para cada
configuración emmera resulta demasiado costoso.
El componente crea fuentes de datos
genéricas bajo demanda. Cuando éstas se
liberan por el cliente, se almacenan en un pool
para su reu<lización.
Almacén de Fuentes
<wc-source-store>
<wc-rule type="wc-rest" size="3"/>
<wc-rule type="wc-socket" size="1"/>
...
</wc-source-store>
El almacén de fuentes de datos se configura
indicando el número de fuentes que se desea
tener disponibles para cada <po de protocolo
usado.
Durante la sesión de trabajo la fuente de
datos obtenida esta reservada, luego se libera
para ser usada por otros clientes
wc-source-store
get(k)
release(s)
get (k)
release (ds)
wc-cliente
wc-sources
get
release
(selected)

@javiervelezreye 32
III. Patrones de Distribución

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
Saber distribuir los comandos a cada una
de las fuentes de datos con las que
operamos debería ser una tarea
transparente al desarrollador
Nivel de Distribución

@javiervelezreye 33

Se requiere operar con diversas fuentes de datos bajo diferentes
circunstancias que vienen marcadas por el <po o contenido del
comando o por las condiciones ambientales.
El componente wc-recruiter se encarga de
localizar una fuente de datos apropiada para el
<po de comando y la devuelve al cliente.
Recruiter
<wc-recruiter data-provider="#p">
<wc-rule exp="[[x]]" source="key1"/>
<wc-rule exp="[[y]]" source="key2"/>
...
</wc-recruiter>
El reclutador es frecuentemente un compo-
nente especíﬁco de dominio sin conﬁguración
aunque pueden encontrarse versiones
declara<vas como la siguiente.
El componente selecciona una fuente
apropiada y la entrega como referencia al
cliente para que opere con ella
wc-recruiter
get (cmd)
wc-cliente
(selected)
ref
get(cmd)
Las reglas aquí sirven para expresar condiciones
bajo las cuales se escoge una fuente determinada.
Una opción de regla más avanzada es esta…
<wc-rule exp="x.size > k" source="key">
<wc-where value="[[a]]" as="x"/>
<wc-where value="[[b]]" as="k"/>
</wc-rule>

@javiervelezreye 34

Se requiere operar con diversas fuentes de datos bajo diferentes
circunstancias que vienen marcadas por el <po o contenido del
comando o por las condiciones ambientales.
El componente wc-broker se encarga de
localizar una fuente de datos apropiada para el
<po de comando y le envía dicho comando.
Broker
El broker es frecuentemente un componente
específico de dominio sin configuración
aunque pueden encontrarse versiones
declara<vas como la siguiente.
wc-broker
command
wc-sources
data
La fuente seleccionada recibe
el comando entrante para su
procesamiento
(selected)
Las reglas de configuración
operan, en este caso, de forma
similar a como lo hacen en el
patrón recruiter
<wc-broker data-provider="#p">
<wc-rule exp="[[x]]" source="key1"/>
<wc-rule exp="[[y]]" source="key2"/>
...
</wc-broker>

@javiervelezreye 35

Tu proyecto opera con un conjunto de fuentes similares bajo un
esquema de compe<ción. Necesitas enviar una solicitud a todas
ellas y extraer una respuesta agregada o selec<va de las mismas.
El componente wc-scaeer-gather ofrece este
comportamiento devolviendo una solicitud
agregada o filtrando la mejor respuesta bajo
algún criterio.
Scaeer – Gather
<wc-scatter-gather data-provider="#p">
<wc-rule source="key1"/>
...
</wc-scatter-gather>
El componente se configura con reglas que
indican la colección de fuentes de datos entre
las que se distribuye la solicitud.
wc-scaeer-gather
wc-aggregator
command
wc-sources
data
data
data
data Los datos producidos por las fuentes son
recolectados por un agregador (ver más
adelante). Si se trata de un comando de es
escritura este flujo no <ene sen<do
(all selected)

@javiervelezreye 36

Se requiere operar con un conjunto de fuentes similares bajo un
esquema de compe<ción. Sin embargo, se pretende aplicar
lógica de balanceo de carga para no saturar a ninguna de ellas.
El componente wc-balancer aplica cierta
polí<ca de balanceo de carga y entrega el
comando a la fuente seleccionada.
Balancer
<wc-balancer data-provider="#p">
<wc-round-robin size="3" policy/>
...
</wc-balancer>
El balanceador se configura especificando un
conjunto de fuentes de datos equivalentes y
un componente que implementa el interfaz de
polí<ca.
wc-balancer
command
wc-sources
data
La fuente de datos se
selecciona por aplicación
de cierta polí<ca específica
(selected)

§  Round – Robin
§  Random
§  Weighted – Round – Robin
§  Weighted – Random
§  S<ky
Tipos de PolíScas
next()
next
Los componentes de polí<cas
implementan una interfaz que indica
la fuente que debe seleccionarse
wc-x-policy

@javiervelezreye 37

esquema de compe<ción. Cada una de ellas se debe u<lizar bajo
condiciones ambientales y de contexto diferentes.
El componente wc-switcher selecciona
automá<camente la fuente de datos
apropiada en función de las condiciones de
contorno.
Switcher
<wc-switcher key="[[x]]" data-provider="#p">
<wc-rule when="real" source="key1"/>
<wc-rule when="fake" source="key2"/>
...
</wc-switcher >
El selector de fuente por contexto se configura
indicando la propiedad (key) que debe
observarse dentro del contexto ambiental.
wc-switcher
command
wc-sources
data
La fuente de datos se
selecciona en función de
condiciones ambientales
(selected)
Al permutar el valor de la variable
ambiental x se cambia la estrategia de
selección de fuentes
{{x}}
Las reglas de configuración determinan
que fuente debe aplicarse según el valor
del la propiedad observada
Un uso par<cular es la configuración
por entornos de desarrollo

@javiervelezreye 38

esquema de compe<ción. Sin embargo, no todas ellas se
encuentran disponibles en un momento determinado.
El componente wc-chain establece una cadena
de fuentes de manera que si una fuente esta
disponible procesa el comando y sino, se lo
pasa a la siguiente fuente en la cadena.
Chain
<wc-chain data-provider="#p">
<wc-rule source="k1" busy="[[b1]]"/>
<wc-rule source="k2" busy="[[b2]]"/>
<wc-rule source="k3" default/>
...
</wc-data-source>
Dis<ntas instancias de fuente se enlazan
formando una cadena de responsabilidad. Si
una fuente está ocupada se delega en el
siguiente elemento en la cadena.
wc-chain
command
La úl<ma regla reﬁere a una fuente
de datos que se encarga de operar
cuando las demás han estado
ocupadas
wc-source
{{x}}
wc-chain wc-source
{{x}}
wc-source
ok
ok
busy
busy
Las reglas incluyen un ﬂag
para marcar cuando una
fuente está ocupada

@javiervelezreye 39

Se requiere operar con un conjunto de fuentes de datos. Sin
embargo, la conexión o el servicio que le da soporte es propenso
a caerse y no ofrece disponibilidad permanente.
El componente wc-retrier reintenta el ataque a
la fuente un número determinado de veces en
caso de fallo para aumentar la probabilidad de
éxito.
Retrier
El componente opera contra una fuente de
datos. Las reglas de conﬁguración indican para
cada <po de comando el número máximo de
intentos (max) y la frecuencia de ataque (ms).
(max) es el número máximo
de intentos a realizar
wc-retrier
command command
wc-source
error
data
cmd #1
error
cmd #2
ok
cmd #3
(ms) es el <empo de
espera entre intentos
El componente <ene
memoria para ges<onar
simultáneamente varios
comandos diferentes
<wc-retrier source="k1" data-provider="#p">
<wc-session cache-provider/>
<wc-rule exp="[[x]]" max="3" ms="300"/>
<wc-rule exp="[[y]]" max="3" ms="5000"/>
...
</wc-retrier>
Las expresiones de regla ayudan a
evaluar el comando entrante para saber
que criterios de reintento aplicarle

@javiervelezreye 40

esquema de compe<ción. Sin embargo, éstas son propensas a
caerse y denegar el servicio durante largo <empo.
El componente wc-circuir-braker detecta estas
fuentes inestables y las desconecta temporal-
mente hasta que vuelven a estar opera<vas.
Circuir Breaker
El componente se conﬁgura con un proveedor
y la colección de referencias a fuentes que
debe u<lizar. Para resetear el estado debe
invocarse el método (reset).
wc-circuit-breaker
command
wc-retriers
data
El patrón es en realidad un
balanceador + una colección de
retriers. Cuando un retrier avisa de
error el componente desac<va la
fuente y prueba con la siguiente
error
El error del retrier
hace que se desac<ve
La siguiente fuente ya
opera adecuadamente
reset()
<wc-circuit-breaker data-provider="#p">
<wc-rule source="key1" time="30"/>
<wc-rule source="key2" time="10"/>
...
</wc-circuit-breaker>
El parámetro <empo (<me) de las
reglas indica el <empo que la
fuente debe estar inaccesible. Por
conveniencia, éste se expresa en
minutos.

@javiervelezreye 41
IV. Patrones de Transformación

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
Acomodar las impedancias entre las esquemas de
datos de las fuentes y los modelos de interacción
de front debería ser una tarea transparente al
desarrollador
Nivel Transformación

@javiervelezreye 42

Algunos comandos o datos deben descartarse para que no
lleguen a su obje<vo final. El criterio de filtro depende del
contenido o las condiciones ambientales.
El componente de filtro deja pasar sólo
aquéllos eventos que verifican determinada
propiedad expresada en componentes de
guarda.
Filter
El componente se configura a través de una
colección de reglas que refieren a los
proveedores de guarda. Su criterio se combina
de acuerdo a una lógica AND u OR.
wc-filter
e e
<wc-filter and>
<wc-rule guard="#A"/>
<wc-rule guard="#B"/>
...
</wc-filter>
<wc-exp id="A" exp="x.size > k" >
<wc-where value="[[a]]" as="x"/>
<wc-where value="[[b]]" as="k"/>
</wc-exp>
<wc-idempotent path="meta.id"/>
wc-guard
event
check
check
event
wc-guard wc-target
El filtro consulta a los
componentes de guarda
Cada componente de guarda
valora la conveniencia de
filtrar el evento
El des<no sólo recibe los
eventos que han atravesado
el filtro
Un uso par<cular permite descartar comandos
de escritura repe<dos (idempotencia)

@javiervelezreye 43

Algunos comandos o datos deben enriquecerse antes de que
lleguen a su obje<vo final. Los datos a incluir provienen del
estado de otros componentes o condiciones ambientales.
El componente wc-enritcher se encarga de
incluir información en los eventos entrantes a
par<r de datos proporcionados por proveedo-
res de contexto.
Enritcher
El componente se configura a través de una
colección de reglas que refieren a los
proveedores de datos cuyas contribuciones
serán añadidas al evento de salida.
wc-enritcher
e e
<wc-enritcher>
<wc-rule path="meta.id" from="#A"/>
<wc-rule path="header.user" from="#B"/>
<wc-rule path="header.app" from="#C"/>
...
</wc-enritcher>
<wc-session id="B" key="usr" level="local"/>
<wc-session id="B" key="app" level="session"/>
<wc-id-factory start="[[n]]"/>
usr
app
Id++
event event'
usr
app
Id=35
El componente enriquece
el evento entrante para
pasarle datos de otros
componentes
Generador de
iden<ficadores únicos
El token de aplicación y
usuario se almacena
localmente y se añade a
la cabecera
wc-id-factory
wc-session

@javiervelezreye 44

Algunos comandos o datos se encuentran en un formato
incompa<ble para ser adecuadamente interpretados por su
des<no. Se requiere una traducción.
El componente wc-translator especifica una
plan<lla de traducción donde se expresa el
formato de salida en función de los datos del
evento de entrada.
Translator
El componente se configura por medio de la
definición de una plan<lla. Cualquiera de las
plan<llas dom- puede u<lizarse.
wc-translator
e e
<wc-translator>
<template>
{ header : {},
body : {
user : [[name]],
pwd : [[password]]
}
}
</template>
</wc-translator>
event event'
El evento a la entrada
representa unos datos en
cierto formato
El traductor expresa los datos del
evento a la salida para acomodarlos
al formato esperado en el des<no
El proceso de traducción
está dirigido por plan<llas

@javiervelezreye 45

Algunos de los comandos o datos están expresados a un nivel de
granularidad demasiado alto y deben ser descompuestos en sus
partes atómicas.
El componente wc-splieer se encarga de
realizar una descomposición del evento
entrante para generar una colección de
eventos más sencillos.
Splieer
La plan<lla recorre los elementos de datos del
evento entrante y expresa el formato para
cada evento de salida.
wc-splieer
e e1 e2 e3
<wc-splitter>
<wc-rule path="cmd.items" as="item"/>
<template>{
owner : [[cmd.user]],
product : {
name : [[item.name]]
id : [[index]],
amount : 1,
price : [[item.price]]
}
}
</template>
</wc-splitter>
La entrada recibe un
evento en forma
compuesta
El componente descompone el
evento en otros eventos
atómicos
wc-target
E
[d1, d2, d3]
d3
e
d2
e
d1
e
Payload de cada evento
saliente
Path donde reside la
colección a par<cionar

@javiervelezreye 46

Algunos de los comandos o datos están expresados a un nivel de
granularidad demasiado bajo y deben ser agregados en una
estructura compuesta.
El componente wc-aggregator se encarga de
realizar una composición de una colección de
eventos atómicos entrantes para generar un
eventos compuesto.
Aggregator
La plan<lla se interpreta en sen<do inverso al
caso anterior. Construye un esquema
complejo desde una colección de items
recolectados en el <empo.
wc-aggregator
e e1 e2 e3
Llegan a lo largo del
<empo eventos atómicos
El componente analiza el iden<ﬁ-
cador de secuencia para saber
cuando emi<r el evento compuesto
wc-target
E
[d1, d2, d3]
d3
e
d2
e
d1
e
<wc-aggregator>
<template>{
cmd : 'basket,
<template
is='dom-repeat'
items='{{items}}'>{
owner : [[user.name]],
products : [[data.prods]]
}
</template>
}
</template>
</wc-aggregator>

@javiervelezreye 47
V. Patrones de OpSmización

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
OpGmizar el acceso a las fuentes
de datos debería ser una tarea
transparente al desarrollador
Nivel de OpSmización

@javiervelezreye 48
VI. Patrones de OpSmización

Algunos comandos de lectura se repiten recurrentemente a lo
largo de la sesión de trabajo lo que provoca una sobrecarga de
las fuentes de datos.
El componente wc-cache es una memoria
intermedia de acceso rápido que descarga de
trabajo a las fuentes cuando el dato se ha
cargado recientemente.
Cache
de persistencia e información acerca del
<empo de vida que residen los datos en
memoria.
<wc-cache time="30" path="cmd.query">
</wc-cache>
El parámetro <empo (<me) expresa
el <empo de vida en minutos de los
datos en cache
La ruta (path) dice a la cache
qué dato del comando de
lectura corresponde a la
clave con que se han
persis<do los datos
wc-cache
command
data
data wc-source
read
read
data
read
wc-target
data
No se dispone de los datos
y se consulta la fuente
Ya se dispone de los datos
y se entregan al cliente
data

@javiervelezreye 49

Algunas fuentes exponen sus colección de datos de acuerdo a
una lógica de paginación. El acceso a esta información debería
realizarse de forma ﬂuida haciendo transparente dicha lógica.
El componente wc-pager es un apoderado que
permite explorar colecciones paginadas de
forma transparente ofreciendo una sensación
de con<nuidad en los datos.
Pager
El componente paginador se conﬁgura
indicando el proveedor de persistencia y el
<empo de vida de las páginas.
<wc-pager time="30"
path="cmd.page"
start="1">
</wc-pager>
El paginador también funciona como una cache a
nivel de página de manera que sólo consulta la
fuente cuando no dispone de la página en local
En este caso (start) indica
la página de comiendo.
wc-pager
command
data
data wc-source
next
read
data
previous
wc-target
data
data
El comando se encarga de
ges<onar el número de página
y enriquecer el payload

@javiervelezreye 50

Algunos <pos de datos requieren un tratamiento transaccional
aunque sus fuentes no lo soporten. Se requiere emular la
transaccionalidad desde el front.
El componente wc-transac<on re<ene el
procesamiento de los comandos entrantes
para que se procesen en bloque sólo a la
llegada de una señal.
TransacSon
El componente transacción se conﬁgura
indicando el proveedor de persistencia donde
se acumulan los eventos antes de enviarse.
wc-transacSon
command wc-aggregator
commit
write
write
write
wc-source
write
write
write
write-all
La transacción suele combi-
narse con un agregador para
generar un único paquete de
datos
<wc-transaction>
<wc-rule when='[[exp]]' commit/>
</wc-transaction>
Todos los comandos se persisten
localmente a la espera de que
llegue una señal explícita de
commit
La expresión (exp) ayuda al
componente a iden<ﬁcar los
comandos que corresponden
a sentencias commit

@javiervelezreye 51

Algunas fuentes de datos operan a un ritmo más lento del que
los datos son generados en front. Se requiere un mecanismo
para no saturar a la fuente basado en el descarte de datos.
El componente wc-throele se encarga de
garan<zar que cualquier comando que se
emita demasiado próximo en <empo a otro
anterior sea descartado.
Throele
El componente se conﬁgura indicando el
<empo en milisegundos que debe aplicarse
como umbral para descartar eventos.
wc-throele
command wc-target
e1 e1
Se descartan todos aquellos
eventos que llegan con una
frecuencia demasiado rápida
e3
e2
e4
e5
e6
e3
e5 Este patrón se aplica bajo la
hipótesis de que la pérdida de
eventos no es signiﬁca<va para el
problema
<wc-throttle ms="[[t]]">
</wc-throttle>

@javiervelezreye 52

Algunas fuentes de datos operan a un ritmo más lento del que
los datos son generados en front. Se requiere un mecanismo
para no saturar a la fuente basado en el encolado de datos.
El componente wc-delayer introduce un
retardo temporal ﬁjo en todos los comandos
que provienen desde el front para no saturar a
la fuente.
Delayer
El componente se conﬁgura indicando el
<empo en milisegundos que debe retardarse
la propagación de eventos y un proveedor de
persistencia.
wc-delayer
command wc-target
e1 e1
En este caso no se pierden
eventos pero se acomoda la
frecuencia de llegada
e3
e2
e2
e3 Este patrón puede suponer un
cuello de botella ya que los eventos
no se pierden, sólo se retardan
<wc-delayer ms="[[t]]">
</wc-delayer>

@javiervelezreye 53
VI. Patrones de Control

Acceso a Datos
Control
Acceso
Transformación
Distribución
OpGmización
AcGvación
Los mecanismos de integración entre las
vistas (componentes UI) y las fuentes de
datos (componentes de daros) deberían
ser transparentes al desarrollador
Nivel de Control

@javiervelezreye 54

Diferentes <pos de fuentes de datos u<lizan dis<ntos protocolos
de acceso. Se requiere abstraer su forma de uso para que operen
de forma homogénea.
Este componente encapsula la complejidad
inherente a un protocolo de uso de una fuente
en un mensaje JSON (comando) que se
propaga como evento en la arquitectura.
Command Provider
El componente se conﬁgura deﬁniciendo los
comandos por propiedades e indicando el
contexto donde se evaluan las propiedades (:)
<wc-command-provider context="[[ctx]]">
<wc-rule command="cinemas">
<wc-property path="cmd.verb" value="get"/>
<wc-property path="cmd.uri" value="/cinemas"/>
</wc-rule>
<wc-rule command="movies">
<wc-property path="cmd.uri"
value="/cinemas/[c]/movies"/>
</wc-rule>
<wc-rule command="sessions">
<wc-property path="cmd.uri"
value="/cinemas/[c]/movies/[m]/sessions"/>
</wc-rule>
...
</wc-command-provider>
wc-command-provider
get(k)
k1 :
k2 :
k3 :
1. Se ob<ene el
comando por clave
wc-cliente
wc-data-source wc-rest
2. se lanza el comando
en un evento
command hasta la
fuente command
3. La fuente reinterpreta el comando
en una operación de protocolo
post()

@javiervelezreye 55

Dis<ntos datos que llegan desde las fuentes de datos en forma
de eventos deben ser retenidos para poder ser consultados
posteriormente en cualquier momento.
El componente wc-data-port se encarga de dar
acceso a los datos de un canal de eventos en
una propiedad de data-binding.
Data Port
El componente se conﬁgura indicando la
fuente de datos (source) a escuchar. El (path)
es la ruta en el evento de datos que determina
en función de (when) donde depositar el dato.
<wc-data-port source="#ds1" path="...">
<wc-rule when="A" data="{{d1}}"/>
<wc-rule when="B" data="{{d2}}"/>
<wc-rule when="C" data="{{d3}}"/>
</wc-data-port>
#ds1
wc-data-port e
e1
e2
{{x}}
{{y}}
A
B

@javiervelezreye 56

Se requiere explorar en profundidad una fuente de datos
orientada a recursos. El progreso de la exploración queda
controlado por propiedades en data-binding.
El componente proporciona un mecanismo
explícito para realizar la exploración contro-
lada por variables y centralizar los comandos
de ataque.
Data Driven Client
de comandos y una colección de reglas que
indican el avance en la exploración cada vez
que una nueva variable toma valor.
<wc-data-client command-provider="#p">
<wc-rule command="cinemas"/>
<wc-rule command="movies" when="[[c]]"/>
<wc-rule command="sessions" when="[[m]]"/>
</wc-data-client>cinemas
movies
sessions
/cinemas
/cinemas/{{c}}/movies
/cinemas/{{c}}/movies/{{m}}/sessions
{{c}}
{{m}}
wc-data-driven-client
command
{{c}}
{{m}} && {{c}}
Se explora en profundidad
un espacio de recursos
Las variables pobladas
determinan el progreso
en la incursión
cinemasmoviessessions

@javiervelezreye 57

Se requiere explorar en profundidad una fuente de datos
orientada a recursos. El progreso de la exploración queda
controlado por eventos.
El componente man<ene el estado de la
navegación y ofrece un mecanismo explícito
de realizar la exploración controlada por
eventos.
Event Driven Client
de comandos y una colección de reglas que
indican el avance en la exploración cada vez
que llega un nuevo evento.
<wc-data-client command-provider="#p">
<wc-rule command="cinemas"/>
<wc-rule command="movies" on="e1"/>
<wc-rule command="sessions" on="e2"/>
</wc-data-client>cinemas
movies
sessions
/cinemas
/cinemas/{{c}}/movies
/cinemas/{{c}}/movies/{{m}}/sessions
wc-event-driven-client
command
e1 (c)
e2 (m) + (c)
Se explora en profundidad
un espacio de recursos
Las variables extraídas del
evento determinan el
progreso en la incursión
cinemasmoviessessions
c
m

@javiervelezreye 58

Se requiere explorar una fuente de datos hypermedia. La
exploración queda controlada por un conjunto de eventos que
representan movimientos sobre el grafo de recursos.
El componente man<ene el estado de la
navegación sobre el espacio hypermedia de
recursos y controla su progreso dirigido por
eventos.
Hypermedia Client
El comando sólo requiere una referencia al
estado/recurso inicial. El resto de estados y sus
comandos asociados se extraen de la
respuesta (response).
root
wc-hypermedia-client
command
Books
Books
Books
Books
mine
shared
add
del
add
item
Book
Book #1…n-1
Book #n
related
Account
Account
purchase
<wc-hypermedia-client command-provider="#p">
<wc-rule start-command="root"/>
<wc-rule response="{{data}}"/>
</wc-hypermedia-client>
Cada relación es un comando
cuya estructura está en la
respuesta del comando
anterior
Cada recurso representa un
estado de la aplicación

@javiervelezreye 59

Se requiere reaccionar contra una fuente de datos cada vez que
se produce un cambio asíncrono en el contexto ambiental donde
se desarrolla el front.
El componente se man<ene a la escucha de los
cambios de las condiciones ambientales que
son objeto de interés reac<vo.
Observer
El componente se conﬁgura con un agente de
escucha (spy) que lanza eventos cada vez que
se producen cambios.
<wc-observer command-provider="#p">
<wc-dom-spy path="css" spy/>
<wc-js-spy target="{{wc}}" spy/>
<wc-event-spy target="{{wc}}" spy/>
<wc-rule on="e1" command="k1"/>
</wc-observer>
3 de los ejemplos de
espía más comunes
Las reglas indican con qué
comandos debe reaccionarse
para cada <po de evento
wc-observer
e command
wc-dom-spy
wc-js-spy
wc-event-spy
dom
e
e3
e2
e1
cmd
e'
e'
e'

Javier Vélez Reyes
@javiervelezreye
3 El Subsistema de
Acceso a Datos en
la Prác>ca
§  Escenario de e-commerce
§  Arquitectura
§  Flujos de Iteración
El Subsistema de Acceso a Datos en la Prác>ca

@javiervelezreye 61
El Subsistema de Acceso a Datos en la Prác<ca

Camisa informal
Bolsillos con botones
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
Camisetas
Camiseta de algodón
Estampado grande
COMPRAR
S M L X XL
VER
Estampado grande
COMPRAR
S M L X XL
VER
Motivo de texto
COMPRAR
S M L X XL
VER
Cuello redondo
COMPRAR
S M L X XL
VER
Estampado a color
COMPRAR
S M L X XL
VER
Hombre Mujer
Pagar
I. Portal de e-Commerce. Escenario

Selector de
categoría
Sudaderas
Selector de
colección
Slider de
colección
Botón de
pago
Botón de
compra

@javiervelezreye 62

II. Portal de e-Commerce. Flujo de Exploración A
Hombre Mujer
Pagar
Sudaderas
Camisas
Camisetas
wc-command-provider
wc-data-port
wc-cache
wc-data-source
wc-rest
wc-data-client
{{category}}
get ('collecGons')
cmd
cmd cmd
Get
/categories/hombre/collections
data
{{collections}}
{{collections}}

@javiervelezreye 63

Hombre Mujer
Pagar
Sudaderas
Camisas
Camisetas
wc-command-provider
wc-data-port
wc-cache
wc-data-source
wc-rest
wc-data-client
{{category}}
{{collections}}
{{collection}}
get ('items')
cmd
cmd cmd
Get
/categories/hombre/collections/
camisas/items
data
{{collections}}
{{items}}
{{items}}

@javiervelezreye 64

II. Portal de e-Commerce. Flujo de Exploración B
Hombre Mujer
Pagar
Camisetas
Sudaderas
Camisa informal
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
wc-command-provider
wc-data-port
wc-cache
wc-data-source
wc-rest
wc-data-client
wc-pager
{{category}}
{{collections}}
{{collection}}
get ('items-next')
cmd
Get
camisas/items?page="2"
data
cmd cmd
{{items}}{{items}}

@javiervelezreye 65

II. Portal de e-Commerce. Flujo de Exploración B
Hombre Mujer
Pagar
Camisetas
Sudaderas
Camisa informal
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
wc-command-provider
wc-data-port
wc-cache
wc-data-source
wc-rest
wc-data-client
wc-pager
{{category}}
{{collections}}
{{collection}}
get ('items-previous')
cmd
cmd
{{items}}{{items}}
data

@javiervelezreye 66

II. Portal de e-Commerce. Flujo de Compra
Hombre Mujer
Pagar
Camisetas
Sudaderas
Camisa informal
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
wc-command-provider
wc-transac<on
wc-observer
purchase
get ('purchase')
cmd
cmd
OK

@javiervelezreye 67

Hombre Mujer
Pagar
Camisetas
Sudaderas
Camisa informal
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
wc-command-provider
wc-data-port
wc-cache
wc-data-source
wc-rest
wc-data-client
{{category}}
{{collections}}
{{collection}}
get ('items')
cmd
cmd cmd
Get
camisas/items
data
{{collections}}
{{items}}
{{items}}

@javiervelezreye 68

Hombre Mujer
Pagar
Camisas
Sudaderas
camisetas
Estampado grande
COMPRAR
S M L X XL
VER
Estampado grande
COMPRAR
S M L X XL
VER
Motivo de texto
COMPRAR
S M L X XL
VER
Cuello redondo
COMPRAR
S M L X XL
VER
Estampado a color
COMPRAR
S M L X XL
VER
wc-command-provider
wc-transac<on
wc-observer
purchase
get ('purchase')
cmd
cmd
OK

@javiervelezreye 69

Hombre Mujer
Pagar
Camisas
Sudaderas
camisetas
Estampado grande
COMPRAR
S M L X XL
VER
Estampado grande
COMPRAR
S M L X XL
VER
Motivo de texto
COMPRAR
S M L X XL
VER
Cuello redondo
COMPRAR
S M L X XL
VER
Estampado a color
COMPRAR
S M L X XL
VER
wc-command-provider
wc-data-port
wc-cache
wc-data-source
wc-rest
wc-data-client
{{category}}
{{collections}}
{{collection}}
get ('items')
cmd
cmd
data
{{collections}}
{{items}}
{{items}}

@javiervelezreye 70

Hombre Mujer
Pagar
Camisetas
Sudaderas
Camisa informal
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
wc-command-provider
wc-transac<on
wc-observer
purchase
get ('purchase')
cmd
cmd
OK

@javiervelezreye 71

II. Portal de e-Commerce. Flujo de Pago
Hombre Mujer
Pagar
Camisetas
Sudaderas
Camisa informal
COMPRAR
S M L X XL
VER
Camisa informal
Cuadro escocés
COMPRAR
S M L X XL
VER
Camisa informal
Cuello abotonado
COMPRAR
S M L X XL
VER
Camisa informal
Tartán de algodón
COMPRAR
S M L X XL
VER
Camisa informal
Tela vaquera
COMPRAR
S M L X XL
VER
Camisas
wc-command-provider
wc-transac<on wc-observer
payment
get ('payment')
cmd
cmd
wc-aggregator
cmd
OK
wc-ﬁlter
logged?
No
Si
wc-data-source wc-enritcher
cmd
wc-rest
Post()
cmd cmd
wc-login wc-ac<vator

@javiervelezreye 72
Conclusión
Conclusión
Para el usuario desarrollador de componentes Web
debería ser transparente la naturaleza de la fuente
de datos, su lógica acceso y ac<vación, y las
necesidades de transformación y op<mización
potenciales.

@javiervelezreye 73
Preguntas
www.javiervelezreyes.com
Arquitecturas Orientadas a
Componentes Web

@javiervelezreye 74
Referencias
Referencias

La Web Orientada a Componentes
Fecha Noviembre de 2015
Lugar Code Mo<on
Páginas 57
Ref heps://goo.gl/mCxm3w
Componentes Web · Arquitecturas Sovware · Frontend · JavaScript ·
Composición · Encapsulación · Reu<lización · Buenas Prác<cas ·
Principios de Diseño · Errores comunes
Principios de Diseño en Componentes Web

Fecha Marzo de 2015
Lugar Polymer Madrid
Páginas 170
Ref heps://goo.gl/t0GpVS
Programación Orientada a Componentes · Principios de Diseño ·
Buenas Prác<cas · Recomendaciones de Diseño y Desarrollo ·
Técnicas de Programación de Componentes Web · Polymer

Arquitectura de Componentes Web. Patrones de Acceso a Datos

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (9)

Destacado

Destacado (18)

Similar a Arquitectura de Componentes Web. Patrones de Acceso a Datos

Similar a Arquitectura de Componentes Web. Patrones de Acceso a Datos (20)

Más de Javier Vélez Reyes

Más de Javier Vélez Reyes (7)

Último

Último (10)

Arquitectura de Componentes Web. Patrones de Acceso a Datos