Lecciones al desarrollar una startup con Java EE y JavaScript – Parte 1

Java 20 banner

 

Durante el desarrollo de Medmigo, he tenido la necesidad de “contarle al mundo” mis observaciones hacia el sentimiento de desarrollar Startups con Java EE y JavaScript, y ya que esta semana alcanzamos la fase beta creo que es el momento apropiado de hacerlo, de otra forma solo estaría comiéndome la torta antes del recreo :).

Contexto:

Isotipo

Medmigo es un sistema de recomendación que usa inteligencia artificial para resolver una necesidad simple (más info aca), nos dimos cuenta que diferente de muchos mercados, en el mercado de medicina las recomendaciones que realmente importan son las de personas confiables (cosa que no ocurre por ejemplo al comprar electronicos en Amazon), y es algo que no encontramos en el mercado, o al menos no como quisieramos.

Asi pues a finales del año pasado y utilizando metodologia lean, nos aventuramos a desarrollar la solución como una actividad paralela a nuestros proyectos de consultoria tradicional, con lo cual he aprendido lecciones bastante interesantes, tanto a nivel personal, empresarial, técnico y fue uno de los motivos por los cuales dejé de bloggear. Hoy en honor al abismo de tux hablare solo de lo técnico.

¿Porque Java?

Una de nuestras motivaciones para elegir Java fue el mercado en si mismo, en nuestro país (Guatemala) las universidades enseñan al menos:

  • .Net
  • PHP
  • Java

No hay que ser un genio para entender que si la oferta supera a la demanda, los precios seran más competitivos, y a pesar de que hubiera sido genial usar Scala o Clojure, pagar el costo monetario por ello en un esfuerzo bootstrapeado seria un suicidio, sin contar que Java es lo suficientemente bueno (no. 1 o no. 2 del mundo) para la tarea. Dicho sea de paso el lenguaje más enseñado en Guatemala es probablemente PHP (y tambien el más odiado).

¿Porque Java EE?

Respuesta corta: Tiene todo lo que un desarrollador pueda necesitar
Respuesta larga:

En el mundo de desarrollo web Java existen basicamente dos opciones, frameworks completos o frameworks ligeros, y esta fue tal vez la decisión más dificil y que hizo llorar a mi niño curioso interior, ¿Cual framework debo usar?.

Asi pues al iniciar el proyecto me di a la tarea de probar los siguientes frameworks ligeros:

Y compararlos contra el virey del desarrollo Java Web:

A nivel personal puedo decir que Vert.x me parecio el más impresionante de los frameworks ligeros, su modelo de procesamiento es similar al de Node.js con la ventaja de que se pueden usar varios lenguajes (Javascript incluido) y se basa en threads y no procesos, siendo que los primeros son más faciles de crear en cualquier sistema operativo.

En este tipo de frameworks, los microservicios son practicamente el alfa y la omega, y contradictoriamente fue aqui donde iniciaron mis dudas. En palabras del gran Martin Fowler “tiene más sentido hacer primero monolitos y luego microservicios”.

Luego de algunos experimentos puntuales donde pude crear un servicio web en 5 minutos, me di cuenta que comparado a experiencias previas muchas cosas iban a ser “manuales” o al menos debia ingeniarmelas para implementar bibliotecas de terceros (-e.g. persistencia en Vert.x, transaccionalidad en Dropwizard).

Como dato adicional debo decir que Spring Boot cuida mejor estos aspectos, sin embargo estaria literalmente casando nuestro proyecto con Pivotal naciendo con vendor lock-in.

Mientras tanto en el mismo periodo de tiempo (incluso en la misma semana) ocurrió el lanzamiento de una tecnología que iba a facilitar mi decisión: Wildfly Swarm

Luego de algunas pruebas me di cuenta que podia crear jar autocontenidos solo con las partes que necesitaba, que en mi caso son:

  • JAX-RS (Servicios Rest)
  • JPA (Persistencia base de datos)
  • JTA (Control transaccional)
  • CDI y EJB (Inyección de dependencias y contexto).
  • Java Mail

Y en resumen me di cuenta que habia desperdiciado dos semanas solo para volver a la misma dirección que usamos en nuestras consultorias, Java EE tiene todo lo que vamos a necesitar y si esto tiene éxito ya tendremos medio camino a microservicios si se usa la arquitectura correcta.

¿Y JavaScript?, ¿Cuanto nos tardamos ?, ¿Que decisiones fueron incorrectas para el MVP? ¿Y que pasa con Java EE 8?. Eso es materia de otro post :).

facebook comments:

Deja un comentario