Como desarrolladores de software, nos solemos enfrentar con decisiones en nuestros proyectos que afectarán a toda la arquitectura de estos de una u otra manera. Una de las decisiones principales que deben de tomarse en el planteamiento de un proyecto web es dónde implementar la lógica y el renderizado del frontend. Esta decisión puede no ser tan evidente a veces y debemos analizar nuestro escenario para encontrar la estrategia más adecuada para renderizar nuestra web.

1. RENDERIZANDO
LA WEB
DEL 2020.

2. Backend Team Lead en Cloud District
Amante de las buenas prácticas y el desarrollo
web
Bloguero tecnológico en adrianalonso.es
Interesado en gestión de equipos y
Management 3.0
En Twitter soy @alonsus91
backend
team lead en
cloud district
¿Quién soy? ...

3. Server Side Rendering
(SSR)
NestJS + Nunjucks
¿Qué vamos a ver? .
Client Side Rendering
(CSR)
Create React App
Rehydration
NextJS
Prerendering
GatsbyJS

4. Como desarrolladores de software, nos enfrentamos
a decisiones que afectan a toda la arquitectura.
¿Qué estrategia de renderizado usamos en nuestro
proyecto y quién es el responsable?
Analizar la estrategia adecuada teniendo en cuenta
requisitos como el performance y coste.
Arquitectura .

5. Glosario de Términos ...
TTFB (Time to First Byte)
El tiempo entre que
pinchas un enlace y
el primer byte de
contenido llega al
navegador
FP (First Paint)
El tiempo que tarda
en pintarse el primer
píxel que haga visible
la web al usuario
FCP (First Contentful
Paint)
El tiempo que tarda en
ser completamente
visible el contenido
que el usuario ha
solicitado
TTI (Time to Interactive)
El tiempo que tarda
una web en ser
completamente
interactiva

6. Suele ser el modelo de Webs
Tradicionales y el renderizado de CMSs
clásicos como Wordpress o Drupal.
Esta estrategia produce un First Paint
y un First Contentful Paint muy rápidos.
Generalmente tiene un Time to
Interactive bajo, ya que no requieren
de mucho javascript.
Suele tener un Time to First Byte bajo,
debido al proceso pesado de
renderización. Se solventa con HTTP
Caches.
Renderizamos el HTML
completamente en el
lado servidor
Server Side
Rendering .

7. Server Side
Rendering .
DEMO 1
NestJS + Nunjucks

8. Client Side
Rendering .
Comúnmente conocidas como
Single Page Applications
Toda la lógica de recuperación de
datos, creación de plantillas y
enrutamiento es responsabilidad del
frontend.
Problemas de rendimiento en
dispositivos móviles.
Solventados por Code Splitting y
estrategias de LazyLoad
Renderizamos el HTML
completamente en el
lado cliente

9. Client Side
Rendering .
El tipo de aplicaciones con esta
estrategia pueden ser Paneles de
administración, Aplicaciones
Corporativas, PWA...
El requisito principal suele ser
interacción buena y fluida pese a una
carga inicial de todos los recursos
javascript.
Se apoyan en soluciones de caché en
cliente como Local Storage o Service
Workers.
Rápido TTFB y lento TTI.
Renderizamos el HTML
completamente en el
lado cliente

10. Client Side
Rendering .
DEMO 2
Create React App

11. Las peticiones son manejadas
por el servidor que renderiza
completamente el HTML.
Una vez renderizada la capa
javascript se monta encima del
HTML resultante mediante la
Rehydration.
Impacto significativo en el TTI,
mejora mucho el FP.
Se solventa con la rehidratación
progresiva.
Rehydration .
Enfoque que intenta
coger lo mejor de los
dos mundos: SSR y CSR

12. Rehydration .
DEMO 3
NextJS

13. Prerendering .
el renderizado ocurre en
la etapa de build,
también conocidos como
JAMstack Sites
Ofrece un FP y un FPC muy
rápidos, ya que el site ya está
prenderizado y servido
rápidamente desde una CDN.
Produce un archivo HTML
separado por cada URL. Desafío
cuando es difícil predecir las urls
con antelación. Builds
Incrementales
Existen muchas soluciones de
renderizado estático para
implementar esta estrategia:
NextJS, Nuxt, Hugo, Gatsby.

14. Prerendering .
Alta Seguridad: reduce las áreas
de ataque al generar el site, sin
depender de llamada al servidor.
Barato y escalable: despliegues
sencillos de build estático, HTML
+ CSS + JS. Solo coste de
almacenamiento y no de
computo.
Apoyado en el boom de
headless cms,:
Strapi, Contentful, Prismic.
el renderizado ocurre en
la etapa de build,
también conocidos como
JAMstack Sites

15. Prerendering .
DEMO 4
GatsbyJS

16. Arquitectura
desacoplada
Altamente escalable y
para proyectos de todos
los tamaños
Gran velocidad y
experiencia de
usuario
Soluciones E-commerce .
https://gatsbylius.com/

17. Caso de Éxito: Zenteo, transformando el servicio de asistencia en carretera.
Desarrollamos la plataforma tecnológica
que permite al usuario acceder a
información sobre el modelo de su batería
de coche a través de la matrícula de su
automóvil y ofrecer un servicio de
recambio a domicilio.
UX + UI: prototipado
Desarrollo de plataforma integral: Web, Panel
de gestión Admin y App de gestión de operarios
Desarrollo en ReactJS con el framework NextJS
Generación de landings de baterías mediante
estrategia de JAMStack
SEO y SEM

18. Resultados
Lighthouse .

19. Workflow
Frontend
Developer
Code
Repository
Continuous
Integration
Live Web
Headless
CMS
Content
Editor
GIT PUSH
CI WORKFLOW
APP DEPLOY
WEBHOOK TRIGGER NEW CONTENT
FETCH CONTENT

20. Server Side Rendering
(SSR)
Conclusión .
Client Side Rendering
(CSR)
Rehydration
Prerendering
BUSCAR EL EQUILIBRIO

21. GRACIAS .