Proof of Concept – Pt 1 – Workspaces
By
Antes de comenzar a explicar la parte de “pruebas”, que realicé para saber si desarrollaba este pequeño proyecto o no, puedes consultar la entrada anterior o la colección completa de las entradas para conocer un poco más acerca de este proyecto:
Tabla de Contenidos
Comencemos aclarando un poco el término: Proof of Concept (Prueba de Concepto, en su traducción al Español).
Proof of Concept
Una Prueba de Concepto tiene como objetivo demostrar la viabilidad de una idea (en este caso), con el objetivo de demostrar o validar si la idea es: rentable, es útil, si puede llegar a funcionar, si el enfoque o punto de vista desde el cual se está considerando es el adecuado, conocer o validar los riesgos, entre otros…
Las pruebas de concepto son fundamentales antes de realizar, desarrollar o materializar una idea que se busque implementar como producto, cabe agregar que el realizarla no asegura que el producto se vaya a realizar o se vaya a llevar a concebir para que sea publicado, hay un camino muy largo considerando tanto el aspecto técnico como comercial.
Si quieres conocer un poco más acerca del tema y a profundidad, puedes consultar el siguiente articulo de asana que está muy bien explicado: Prueba de concepto (POC): qué es y cómo implementarla, ya que el tema es bastante interesante pero a su vez algo extenso y especializado, sale del alcance de este articulo.
Por supuesto, antes de pasar con este punto, se realizó un tipo de propuesta en donde se establecio tanto el objetivo, como las caracteristicas generales, el planteamiento del problema o caso de uso inicial, etc… nada realmente muy formal o sofisticado; ya que es algo “personal”…. pero que si en algún momento se dá la oportunidad de hacerlo comercial, pues ya se tienen establecidas las bases o el fundamento sobre el cual se comenzó el proyecto.
Como bien ya expliqué, este proyecto es pequeño, es más que nada personal y actualmente no hay intenciones de comercializarlo, entonces no es del todo necesario aplicar una prueba de concepto al 100% pero si se realizaron unas pruebas para ver si el enfoque optado era viable como se detalla más adelante, es por eso que se mencionó este punto.
Busqueda del enfoque
Esta fase fue relativamente sencilla porque la parte base ya la tenia, los objetivos especificos o funcionalidades básicas que necesitaba que eran:
- La definición de los datos y su estructura
- Una relación “sencilla” entre los datos
- Poder almacenar esos datos, para generar la persistencia y consumirlos o modificarlos
- Poder implementar las operaciones básicas para gestionar esa información, es decir, un CRUD (CREATE, READ, UPDATE, DELETE o Crear, Leer, Actualizar, Eliminar por sus siglas en Español)
- Poder tener una vista para generar esa información, consumirla y representarla
- Y la parte fundamental: Como poder interactuar con esa información para poder visualizar los sitios dentro de la misma app
Hasta este momento, la mayor parte es “sencilla” si tienes algo de experiencia trabajando con parte de la capa que interactua con el Sistema Operativo (SO) al utilizar un lenguaje de alto nivel. Para no complicarme las cosas opté por usar un lenguaje que ya conozco; dado que es algo personal, no queria llevarme mucho tiempo, ya tengo el conocimiento acerca de el o los procesos que tengo que implementar y como funcionan.
Así que la técnologia a utilizar era: Javascript (JS) o TypeScript (TS) de preferencia, al inicio tenia pensado en una solución que fuera únicamente usando algo local y sin agregar técnologias web al 100%, investigando no encontré algo que me gustará para hacer una implementación nativa solo con NodeJS. Esto por supuesto pensando en crear algo lo más acercado a una aplicación local o instalable, algo que utilizará las características de lo nativo del sistema.
La opción más mencionada entre algunas era ElectronJS, pero tenia que meter técnologias web al 100%, entonces era para considerarse (aunque no me gustará del todo)… Investigando y probando entre algunas alternativas, se quedó Electron como la opción más viable pero aquí el detalle era justamente:
“Ok, si voy a estar trabajando únicamente con información relacionada al Workspace y el Workspace tiene relación con el Space y el Space a su vez, tiene la info acerca del sitio o sitios que necesito siempre o casi siempre tener abiertos… ¿Como le voy a hacer para renderizar la página sobre la cual necesite trabajar?“
Quizá no se comprendan los términos Workspace y Space hasta el momento… más adelante en articulos sucesivos se va a aclarar el porque de estos términos.
PoCs de implementación
Aquí es justamente en donde entramos en la parte de las Pruebas de Concepto, con el proposito de validar justamente que: Los objetivos propuestos, con la técnologia escojida y con las herramientas seleccionadas, se pudieran llevar a cabo.
Las opciones que se me ocurrieron para atacar ese dilema que me atormentaba fueron:
- Un frame o un Iframe: Para poder renderizar el sitio que deseé pero sin salir de la app misma
- Intercambiar la vista: Entre la solución en sí y el sitio deseado para lograr el mismo fin
- Utilizar más de una instancía de la app en el Front-end (FE): Esta realmente no se me ocurrió hasta ahora pero igual tendría sus detalles ocultos…
- Un tipo de WebView: Para realizar lo mismo (que está opción no se me ocurrió pero si la encontré en la marcha)
Pero creo que va a ser más viable que toque cada una de las pruebas de forma independiente… Así que recuerda: Si te interesó conocer o probar la solución, o quizá conocer acerca de las lecciones aprendidas durante el proceso.
Te invito a seguir las siguientes publicaciones en este mismo blog o directamente puedes encontrar los articulos relacionados en:
Happy coding 🖖, # shutdown –halt