Reflexión: Decenas de lineas

Muchas lineas de código he escrito en el transcurso de la mañana, a pesar de que son pocas comparándolas con la cantidad que faltan para llegar a una versión estable del proyecto, después de todo, estoy programando en un lenguaje que no se acomoda a mis gustos. Pero cómo es que estoy programando en un lenguaje que no me gusta?

— Para llegar a este punto he pasado por una larga historia. Todo empezó hace aproximadamente 6 meses, mi compañero y yo decidimos desarrollar un proyecto de forma separada, este consistía en una plataforma web robusta para la gestión de grupos y semilleros de investigación de nuestra Universidad. La idea era dividir ese proyecto en dos subproyectos, donde los conceptos de Backend y Frontend entrarían en juego, el funcionamiento es bastante sencillo de entender. — Luego de 4 meses me di cuenta que habían unas cuantas variables que no tuvimos en cuenta a la hora de tomar la decisión de la arquitectura de la plataforma, se trataba de la variable Tiempo y Experiencia, ya que al usar ese tipo de arquitectura debíamos usar nuevas tecnologías en el lado del cliente (frontend), razón por la cual duré y avancé aproximadamente el 15% del software usando una reconocida y potente librería creada por Facebook, llamada ReactJS (ademas incluí Redux para el control de estados), el problema era que el tiempo de desarrollo se estaba extendiendo a medida que las cantidad de operaciones internas en el sitio web aumentaba, y ademas me encontré con un problema bastante grave que la librería de la red social no podía resolver de forma autónoma, dicho inconveniente consiste en que las direcciones (o url) se manejaban de forma temporal y privada, es decir, la dirección http://localhost/dashboard contiene el segmento /dashboard que consiste en la url temporal que cambia estaticamente cada vez que los children (componentes hijos) se renderizan, el problema también radica en que esas url resultan imposibles de recargar en el navegador debido a que no hay un servidor que las esté escuchando, aunque esto se resuelve usando renderizado de javascript del lado del servidor (con NodeJS o .Net Core), pero hacerlo de esa forma resultaba mas complicado ya que existen algunas restricciones a la hora de seleccionar los lenguajes para montar un servidor. Posteriormente, implemente Net Core ya que estaba dentro de los frameworks aceptados por el servidor (y la universidad), también logré pasar todo el renderizado del cliente al lado del servidor y combinar toda la arquitectura con el motor de plantillas Razor de .Net, pero también hice algunos cambios en cuanto a la arquitectura del proyecto ya que el manejo del backend y frontend desaparecerían, quedando al final uno solo.

Luego de un mes de estar usando una combinación de distintas herramientas, lenguajes y framewoks; ReactJS, Redux, C#, TypeScript, Razor. Me topé con otro problema, consistía en uno de los mayores problemas que me había encontrado hasta el momento y que había pasado por alto por razones obvias… Net Core comparte gran parte de su arquitectura con .NET, aunque este primero lo supera en cuanto a compatibilidad, ya que es posible ejecutarlo en unos de los sistemas operativos mas importantes hasta ahora (GNU Linux, MS Windows y Mac), en fin, el problema resulta en que las conexiones con bases de datos Oracle aun no son posibles, en cambio en sistemas que no son Net Core (.Net) si es posible.

Duré unos cuantos días pensando que hacer con el desarrollo, ya que el tiempo se estaba agotando y todos mis intentos por hacer algo a mi gusto (y acorde a los términos de la universidad) habían fracasado. Tuve que migrar todo lo que pude a un proyecto propio de .Net, exactamente Net MVC con Razor, con la idea de que a corto plazo debería poder incrustar pequeños componentes de ReactJS (como para usar algo que se ajusta a mis gustos)… Actualmente voy en un 40%, eso significa que en menos de un mes logré adelantar y superar todo lo que había realizado en mas de 4 meses, ademas tengo acceso directo a la base de datos Oracle del servidor y ajustarla ante cualquier cambio necesario. Algunos se preguntarán — ¿Que sucedió con la idea de la separación en Back y Front? — Decidí dejar todo lo relacionado a tareas de administración en el lado del servidor y no tener que usar API para todo sino que unicamente para información publica, es decir, que cualquier usuario no autenticado pudiera consultar determinados recursos en formato JSON.