Cómo hacer un sitio web WordPress descentralizado

PoP (https://getpop.org) es un framework de código libre para crear sitios web basados en WordPress, que apunta a romper el monopolio de la información de las grandes redes sociales mediante la vinculación de sitios web autónomos entre sí. Sitios web construidos con PoP tienen una arquitectura descentralizada, lo que les permite de compartir sus datos unos con otros, y los usuarios de los diferentes sitios web pueden interactuar entre sí, sin necesidad de unirse a un servicio centralizado como Facebook o LinkedIn. De esta manera, la unión de todos los sitios crea una red más amplia compuesta por diferentes comunidades, las cuales son dueñas de sus propios datos, almacenándolos en sus propios servidores, y decidiendo cómo compartirlos y con quién.

PoP trabaja combinando WordPress y Handlebars (javascript templates) en un framework con arquitectura MVC. Actuando como controlador, PoP intercepta los resultados de la consulta de datos de WordPress, genera una respuesta en JSON y alimenta este código JSON a Handlebars para ser transformado en HTML. El resultado es un sitio web dinámico, en el que el back-end es completamente WordPress, pero el front-end se construye utilizando javascript.

En esta presentación, veremos una introducción a PoP, cuáles son sus características principales, una descripción técnica de cómo funciona, y analizaremos sus posibles usos, demostrando casos concretos de aplicaciones que se pueden construir usando este software.

Transcript

1. la “Plataforma de Plataformas” Leonardo Losoviz https://getpop.org
2. URLs PoP https://getpop.org/es/ PoP Demo https://demo.getpop.org/es/ GitHub https://github.com/leoloso/PoP
3. Qué es PoP? PoP combina WordPress y Handlebars en un framework con arquitectura MVC, para crear sitios web de tipo Single-Page Application: WordPress es el model/back-end Templates de Handlebars es el view/front-end El PoP engine es el controller
4. Cómo funciona? Cuando el usuario hace click en un link... Front-end Back-end
5. Cómo funciona? 1 PoP intercepta la solicitud del usuario en el front-end y lo envía al servidor web utilizando AJAX Front-end Back-end Request Request: AJAX
6. Cómo funciona? 2 El controlador de PoP procesa la solicitud, y obtiene la data de WordPress Front-end Back-end Request Request: AJAX Data
7. Cómo funciona? 3 PoP genera una respuesta en JSON, y alimenta el código JSON hacia el front-end Front-end Back-end Request Request: AJAX Response: JSON Data
8. Cómo funciona? 4 PoP envía el código JSON a Handlebars, quien genera el código HTML usando sus templates javascript, y se lo pasa a PoP. Front-end Back-end Request HTML Request: AJAX Response: JSON Data
9. Cómo funciona? 5 PoP inserta el HTML en el DOM y ejecuta funciones javascript definidos por el usuario de los nuevos elementos. Front-end Back-end Request: AJAX Response: JSON Data Request HTML Response
10. Principios de diseño
11. #1: API PoP proporciona al sitio de WordPress de su propia API: Disponible a través de HTTP Simplemente añadiendo a cualquier URL: output=json
12. #2: Descentralizado La respuesta es un código JSON uniforme Todos los sitios web PoP pueden comunicarse entre sí Obtener/processar data en tiempo real Peticiones POST Contenido generado por el usuario es almacenado en el sitio web de fuente.
13. Qué se puede hacer con PoP?
14. Red social Funcionalidades extraídas de varias redes sociales: Twitter/Facebook/Medium/Reddit Demo en https://demo.getpop.org/es/
15. Red social decentralizada Demo entre: https://getpop.org/es/ https://demo.getpop.org/es/
16. Red social niche/decentralizada => Twitter/Facebook/Medium/ Reddit (con WooCommerce) Tienda decentralizada => Amazon Agregador de contenido => Digg Server back-end para mobile apps Micro-servicios Algunos posibles usos
17. Características
18. Single-Page Application Experiencia de usuario similar a una aplicación de escritorio Se puede configurar: Cuáles páginas precargar Cuáles páginas peticionar al servidor
19. HTML desde el servidor La primera carga de la página produce HTML desde el servidor A partir de la 2nd página, el SPA toma el control HTML es producido en el cliente usando javascript Isomorfismo de código El mismo código genera el HTML en el cliente y en el servidor
20. CDN de contenido Contenido dinámico (o mutable) es convertido en estático (o inmutable) al servirlo a través de un Red de entrega de contenidos (CDN) Lo mejor de ambos mundos: Contenido aún es generado a través de WordPress Pero se lo puede cachear como si fuera proviniente de un generador de sitios estáticos
21. Offline first Capacidades Offline first provistos a través de Service Workers el sitio web funciona sin conexión a internet el rendimiento aumenta al reducir las solicitudes de red las páginas se cargan inmediatamente (desde el segundo acceso en adelante) Es una Aplicación Web Progresiva (PWA)
22. Particularidades
23. Estado de la aplicación Operaciones Read: el estado se mantiene en el front-end Operaciones Create/Update/Delete: ejecutadas en el servidor no hay estado dual, no hay necesidad de sincronización
24. Estado de usuario Aplicación diseñada tanto para usuarios logueados y no (aún) logueados Coherente entre páginas con/sin estado de usuario Sincronizado entre pestañas del browser
25. Flujo de ejecución Model y Controller (lógica de la aplicación, flujo de ejecución) reside en el back-end Diferente a javascript frameworks modernos (eg: AngularJS)
26. Características del front-end
27. Targets Cualquier página puede ser cargada en cualquier pageSection Simplemente especificando el atributo “target” en el link, apuntando al pageSection correspondiente
28. Formatos Información puede ser visualizada en múltiple formatos Listas Grillas Mapas Charts Etc
29. Presentación Múltiple estilos de presentación Código extra mínimo puede proveer diferentes funcionalidades: Imprimir Embed
30. Pestañas Muchas páginas pueden ser abiertas simultáneamente Páginas permanecen abiertas hasta ser cerradas Se le pregunta al usuario de re-abrir las pestañas de la sesión anterior
31. (Pre)carga en el fondo Páginas pre-cargadas, estado del usuario, sincronización Vistas iniciales Estado del usuario (logueado => obtener data) Estado del usuario relacionado a la página (eg: Likes) Notifications de usuario Data no cacheable (ej: número de comentarios en el post)
32. Interceptors Cambia la pestaña a una página ya cargada Renderiza vistas inmediatamente Permite deep-linking a funciones javascript, usando una URL real
33. Comparación: API de PoP con WP REST API
34. Similitudes Puede exportar cualquier tipo de información: /posts /eventos /usuarios /tags
35. Diferencias No es RESTful (al menos no actualmente, pero puede ser implementado) Links mantienen la misma URL como en WordPress API sin documentación La API pública es provista automáticamente Desarrolladores pueden enfocarse en hacer el sitio web, no la API Carga inmediata (no se necesita una petición extra para traer los datos)
36. Cómo funciona
37. Templates topLevel, pageSections, blocks/blockGroups modules
38. Jerarquía de templates Jerarquía top-down: 1 topLevel contiene N pageSections 1 pageSection contiene N blocks/blockGroups 1 blockGroup contiene N blocks/blockGroups 1 block contiene N modules 1 module contiene N modules (al infinito)
39. Template: topLevel = Jerarquía de WordPress Home/Single/Page/Archive/etc
40. topLevel
41. Template: pageSection Es una sección física/funcional en el sitio web
42. pageSections
43. Template: block Es un componente independiente Mantiene su propio estado Puede ser añadido a diferentes pageSections, e individualizado bajo cada uno
44. blocks
45. Template: blockGroup Es un tipo especial de block Colleciona/envuelve otros blocks Sincroniza el estado entre ellos
46. blockGroups
47. Template: module Puede ser: Una funcionalidad atómica/reusable Una composición de modules
48. modules
49. Modularity
50. Atomicidad/reusabilidad Un module está compuesto de: Archivos PHP Templates Handlebars .tmpl Archivos .js Archivos .css
51. Composable module Modules pueden construir unos sobre otros Separación de intereses (Separation of Concerns) Collaboración entre desarrolladores
52. Estructura del JSON
53. Limpia/Mínima Database => única per topLevel Dataset => único per block Variables de estados => únicos per block Configuración => única per pageSection, block y module
54. Database Mantiene relaciones/estructura entre objetos (no es una estructura plana, de un único nivel) Cumulativa Permite no volver a peticionar información ya cargada
55. Observaciones
56. “1. Re-aprovechá!” DRY (Don’t Repeat Yourself) WordPress: funcionalidades provistas por la comunidad Isomorfismo: frontend/backend/email HTML del mismo código Módulos: todo es re-usable Arquitectura descentralizada: micro-servicios
57. “2. Desasociá!” Diseño de la vista (Handlebars javascript templates) Configuración de la vista Funciones javascript Estilos Base de datos Inyección de dependencias
58. “3. Cacheá!” Varios niveles de cache: Cache en el servidor (WP Super Cache) Cache de configuración CDN de contenido / CDN de recursos Service Workers
59. Veamos el código!
60. Templates de Handlebars
63. Módules internos
66. Inicializando atributos
68. Configuración
71. Ejecutando Javascript
76. Cargando data
79. Cargando data externa
82. Variables entrada/salida
85. Acciones
88. Data fields
91. Cambiar dominio del obj.
95. Lo que viene
96. Estado del Proyecto
97. SukiPoP https://getpop.org/es/campaign/
98. Gracias! Preguntas? Leonardo Losoviz leo@getpop.org https://getpop.org https://github.com/leoloso/PoP