shaba/one
1
0
Fork 0
mirror of https://github.com/OpenNebula/one.git synced 2025-01-12 09:17:41 +03:00
Code Releases Wiki Activity

M #~: Remove useless fireedge files (#47)

Browse Source
This commit is contained in:
Sergio Betanzos 2020-06-24 15:59:51 +02:00 committed by GitHub
parent bfd78f1646
commit 8a9f30ee30
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 0 additions and 74 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
src/fireedge/introduccion.txt
View File

@ -1,74 +0,0 @@
El diseño del siguiente codigo esta basado en su totalidad en Javascript (ES6).
- **NodeJS** con **Express** para el backend.
- **React**, **Redux** para el front.
- **Webpack** para el transpilado de la aplicacion.
- **NPM** para la gestion de los packages.
Cuando se transpila el código generado funciona tanto en el backend como en el frontend (Server-side Render)
#Motivacion:
en lo personal el sunstone actual esta lleno de inconvenientes los cuales mencionaré sin profundizar:
- Dependencias: muchas de las mismas son muy viejas y actualizarlas seria un riesgo de que no funcionen partes del sistema. tampoco se usan las dependencias en su totalidad.
- Estado global: en el front end no existe un estado global al cual hacer uso para los diferentes componentes del mismo.
- Reactividad: no es reactivo. se hace uso de JQuery y de handlebars. esto hase que al querer hacer algun cambio debes de tambien instanciar los callback para que pueda funcionar despues. tambien hace complicado la busqueda de errores en el codigo.
- Manejo del DOM: ya que su fuerte es el hacer uso de jQuery el manejo de Clases y Id son indispensables, esto tambien puede traer uns serie de consecuencias.
- Respuestas del XMLRPC: hay llamadas que al ser cambiadas a JSON pueden mutar (en vez de ser objetos pasan a ser arrays y viceversa).
- Configuracion: es simple la instalacion del sunstone, pero ya es mas complicado al momento de usar el memcache y demas cosas para usar en produccion.
- Traza de errores: es dificil hacer el seguimiento del codigo ya que no hay herramientas especializadas para el debug.
- Reglas de LINT: no posee.
- Los test e2e: se usa readiness (Ruby).
Ventajas:
- Dependencias actualizadas y testeadas.
- Eliminacion de recursos deprecados como Bower y Grunt, para el transpilado, JQuery y handlebars para el manejo de vistas.
- Creacion de estado Global: al momento de querer hacer consulta a un resurso se puede saber conectando el componente a redux.
- Reactividad: no se debe de manejar las vistas y las acciones por separado.
- Uso de API REST: se puede usar tambien para otro tipo de aplicaciones web.
- Reglas de LINT: el codigo se hace mas legible.
Dependencias:
- Principales: Node, Yarn, ZeroMQ
- Descargadas al hacer uso del comando "Yarn o nom start":
* Sistema: React,NodeJS,Helmet,Redux.
* Desarrollo. Test y compilacion: Webpack, Babel, Cypress, Sass.
Herramientas de Debug:
- Google Chrome (Browser).
- React Developer Tools (Chrome plugin).
- Redux DevTools (Chrome plugin).
- Clear Cache (Chrome plugin).
Compilacion:
Server Side Rendering: al compilar una vez teniendo las dependencias instaladas Webpack se encargara de generar el codigo (Proceso) que estara ejecutandoce en node (Sunstone server) y tambien genera el javascript usado en el Browser (Cliente).
Memcache:
no seria necesario el uso del memcache, actualmente se usa solamente para identificar el usuario del front con el backend, para esto se usaria un jwt, que es un token, dentro tuviese el id del usuario y el opennebula token, esto estaria cifrado por una clave que se guarda en el archivo config.yml
Views
la idea es mantener las vistas (el concepto de vista seria la asociacion de recursos). esta "vista" estaran en los template de group. ya que cada usuario estaria almenos en un grupo. el orden seria el siguiente:
- Al conectarme buscaria los grupos que el usuario posea.
- Dependiendo del grupo del usuario se mostraria las diferentes vistas (estas vistas se guardarian cifradas en base64 ejemplo:
VIEWS = [VIEW1="template_en_base64", VIEW2="template_en_base64", VIEW3="template_en_base64"]).
- Para que un usuario pueda ver una vista particular:
* se puede seleccionar una vista por defecto en el usertemplate, estaria cifrada en base64 ejemplo: DEFAULT_VIEW = "VIEW3".
* se puede colocar una vista en particular cifrada en base64 ejemplo: VIEWS = [ VIEW1="template_en_base64", VIEW2="template_en_base64" ]
CONSULTAR:
-que pasaria si en una federacion posee un namespace diferente a one.