¿Deberíamos usar Java para nuestro back-end de inicio?

Abordemos los términos clave que usó en su pregunta: inicio y backend.

El inicio implica que todavía está buscando un problema para resolver. Eso también sugiere que realizarás muchos experimentos para validar tus teorías sobre lo que la gente quiere. Por lo tanto, use cualquier idioma y herramienta que lo pondrá en funcionamiento más rápido. La optimización excesiva en este punto es ridícula si está tratando todo como un pico de prueba cuyo objetivo principal es aprender lo más rápido posible (para conservar la mayor cantidad de capital posible).

Una vez que encuentre su problema a resolver y esté enfocado en iterar la solución, estará fuera del modo de inicio y podrá enfocarse en “mejores” o “mejores” soluciones. Hasta entonces, la velocidad al mercado es tu amiga.

El backend implica que la interfaz es la clave, no la implementación inicial. ¿Cuánta lógica se está ejecutando en el servidor? ¿Es el back-end esencialmente un almacén de datos para sus aplicaciones front-end? Tal vez realmente no necesite implementar su propio backend y pueda aprovechar una de las muchas soluciones de BaaS que existen.

Por ejemplo, actualmente estoy evaluando DreamFactory para respaldar una aplicación web de una sola página. Expone una interfaz REST a los servicios más tradicionales como bases de datos y autenticación de usuarios. En nuestro caso, la necesidad de lógica en el backend se ha minimizado y podemos concentrarnos en el flujo de datos.

Tomando las implicaciones de esos dos términos juntos, supongo (como espero que lo sea) que reescribirá cualquier código que se desarrolle hoy, ya sea a medida que descubra nueva información sobre lo que sus clientes realmente quieren, a medida que golpea ” problemas de éxito “en torno al escalado, o porque usted pivota y tira todo excepto su base de usuarios (y tal vez incluso los abandona).

Las decisiones comerciales que tome ahora son inmensamente más importantes que las técnicas y la creación rápida de prototipos es su amiga en términos de aprender sobre su mercado. Si más tarde descubre que el backend es su cuello de botella de crecimiento, es probable que haya generado los recursos para contratar expertos para refactorizar, reescribir o replantear el problema (puede ser tan simple como el equilibrio de carga o el almacenamiento en caché).

Al releer su descripción de la situación, también me pregunto qué tan grande ha sido el proyecto que tomaron sus graduados de CS antes. Como profesor de CS, me encuentro haciendo todo lo que puedo para darles a los estudiantes la oportunidad de trabajar en proyectos que son lo suficientemente grandes como para impulsar sus habilidades más allá de ser capaces de una solución de fuerza bruta de última hora la noche antes de que las cosas se vencen. Trabajar dentro de las limitaciones del término académico generalmente significa que los proyectos son ridículamente pequeños en comparación con lo que sucede en los proyectos del “mundo real”.

Si la única experiencia de desarrollo que ha tenido su equipo es en el contexto de la escuela, querrá gestionar la complejidad del proyecto en consecuencia. Concéntrese en hacer que funcione primero, que sea mantenible en segundo lugar y que sea “óptimo” o “eficiente” en un tercio distante (hasta que el rendimiento se convierta en un problema de “hacer que funcione” y obtenga la primera prioridad). Obviamente, aproveche el conocimiento de sus algoritmos y estructuras de datos para implementar algoritmos razonables en términos de complejidad de tiempo, pero cualquier cosa que no sea parte de la especificación que define el “trabajo” debe tratarse solo cuando esté a punto de convertirse en un problema.

Y, una última pregunta que debe hacerse: ¿”costará” más tomar una decisión más tarde que ahora? Si es así, retrase esa decisión. Asumiendo que le tomará el mismo tiempo aprender un nuevo idioma más tarde, hágalo más tarde. Es casi seguro que le cueste menos aprender un nuevo idioma y volver a implementar una solución de trabajo en otro idioma que aprender un nuevo idioma e intentar resolver su problema al mismo tiempo, si no por otra razón, estará más concentrado en las características del lenguaje que son directamente aplicables y tienen una buena solución conocida para comparar.

tl; dr : concéntrese en el cuello de botella del momento, que es poco probable que sea la elección del idioma del backend. Cree algo rápidamente, trátelo como un pico de prueba o prototipo, y aprenda lo más que pueda sobre el mercado y su solución propuesta en el proceso.

¡Los mejores deseos en tu aventura!

Java es bastante interesante. Hace unos años, muchos desarrolladores se cansaron de Java y exploraron otras tierras. A menudo cambiaron a lenguajes interpretados como PHP, Python, Ruby o más lenguajes esotéricos como Erlang.

Sin embargo, Google a través de Android pudo demostrar que Java en sí mismo no es tan terrible como lo recordamos (siempre y cuando no tenga que usar J2EE o Swing). También hay una tendencia “hipster” que parece indicar que Java es realmente genial nuevamente. Mucho de eso tiene que ver con dos cosas:

• la JVM
• la increíble cantidad de bibliotecas de alta calidad

Dicho esto, para muchos de nosotros, escribir Java todo el día no suena atractivo. Si va a confiar en la pila Java, hay una larga lista de otros lenguajes JVM que son maduros y funcionan bien con las bibliotecas Java (es decir: Scala, Groovy, JRuby, Clojure). Siempre puedes mezclar y combinar.

Contratar desarrolladores de Java no es demasiado difícil, ya que la mayoría de los estudiantes que salen de la escuela aprendieron Java, pero encontrar grandes ingenieros de inicio que quieran escribir Java es bastante difícil.

Nota al margen: si está apuntando a Android, manténgalo simple, quédese con la pila oficial incluso si le apetece otro lenguaje JVM mejor.

Todavía hay muchas razones para usar la tecnología de Java para su nuevo inicio, pero también puede considerar usar una solución más “rápida / flexible” en paralelo (Ruby, Python, Node …). Un entorno multilingüe aporta mucho valor tanto a la empresa como a los ingenieros, algo que la comunidad Java parece estar descubriendo lenta pero seguramente.

Java atrae principalmente a ingenieros con formación más clásica que buscan patrones cómodos, repetitivos y bien conocidos. Estarán acostumbrados al lenguaje, sus herramientas y su ritmo natural. Puede que no sean los desarrolladores más curiosos, pero son confiables (si elige los correctos, obviamente).

Espero que esto te ayudará

Java es una buena opción por muchas razones. Ciertamente es un lenguaje más agradable que PHP. Tiene excelentes herramientas de desarrollo para Java: IDE, sistemas de compilación, herramientas de CI, Contenedores, Bases de datos tanto SQL como NoSQL, marcos de servicio REST, analizadores JSON.

Casi todo lo que quieras hacer tiene una biblioteca. Por lo general, también de código abierto.

La gran victoria es que ya tienes experiencia en ese idioma.

Ciertamente, en los últimos 15 años, más de tres compañías me han visto codificar un extenso código del lado del servidor en Java. A menudo usando Spring. Y mi lugar de trabajo actual usa Java en una aplicación web que atiende a 13 millones de usuarios al mes, sin sudar.

Entonces sí, recomendaría ir por ese camino.

PERO: ¿Cuál es tu aplicación? Si es una cosa de estilo CMS, entonces tal vez sí: WordPress / PHP sería mejor. ¿Tal vez sería mejor Javascript y el lado del servidor node.js con el lado del cliente móvil angular / iónico? Difícil de saber Pero sea lo que sea, podrá hacerlo en Java.

Eche un vistazo a la Plataforma CUBA, un marco de código abierto, debe ser sencillo para que pueda comenzar y continuar su back-end debido a la herramienta CUBA Studio – RAD que viene junto con la plataforma.

Vea aquí cómo puede tener sus primeras aplicaciones en funcionamiento en minutos.

Si está creando prototipos de un producto o una idea y necesita un cambio rápido, no le recomendaría que lo haga en Java. Le recomendaría que utilice cualquier servicio externo para eso (Games Park o MongoDB o AWS Dynamo DB) sería bueno. Puede llamar a las cosas directamente desde Android y iOS y completar su prototipo. Una vez que haya terminado su prototipo o primera ronda de aprobación, sería una buena idea introducir Java en la imagen, ya que le daría una mejor escalabilidad, durabilidad y capacidad transaccional. Para las startups, el tiempo de comercialización es un factor clave, por lo que no recomendaría desarrollar el backend de Java al principio.

Utilizo Google Endpoints (Java) para escribir backend para mis aplicaciones y diría que es un marco REST bastante agradable que se ejecuta en el alojamiento en la nube que no le costará nada al principio.

No consideraría PHP como una opción.

Node.js puede ser una alternativa, pero depende del tipo de aplicación que escriba. Como tiene un ingeniero eléctrico en su equipo, puedo suponer que su backend utilizará muchos procesadores para realizar cálculos difíciles, por lo que es menos adecuado para Node.js y más para Java.

Me quedaría con Java.

El problema con un backend de Java es su gran consumo de recursos. Por ejemplo, configuré Apache Tomcat®, un motor de servlet de Java para un cliente, e instalé Pentaho – Business Analytics Platform para darles una idea del motor de informes. Solo ejecutar el Tomcat Java VM casi mata al servidor: mi cliente tuvo que actualizar a un servidor mucho más grande, solo para manejar la consulta ocasional de informes de Pentaho.

Si su backend no tiene que manejar mucha carga, entonces Java es una propuesta viable. Pero si necesita manejar un rendimiento paralelo masivo a un costo mínimo, en mi opinión, estaría mucho mejor con PHP o Python.

Gracias por el A2A. Java es una buena opción en su caso porque su equipo ya conoce el lenguaje, pero tenga en cuenta que su tiempo de desarrollo inicial es solo una pequeña fracción del trabajo que se destinará a su backend. Debería leer sobre las lecciones aprendidas en Netflix cuando cambiaron de Java / Scala a un backend JavaScript NodeJS en gran medida. En resumen, descubrieron que JavaScript era mucho más amigable con los recursos que Java, lo que significa que se requieren menos servidores para servir la misma cantidad de tráfico (una gran ganancia para una empresa que opera a su escala), y que era más fácil de construir y mantener las mismas aplicaciones en JavaScript que Java.

También depende de la escala en la que piense que estará operando. Java está muy bien establecido en la elección de “empresa” en la industria de la tecnología, y siempre podrá encontrar desarrolladores que lo ayuden a mantenerlo. He escrito una cantidad decente de Java a lo largo de los años, pero nunca ha sido mi favorito. Personalmente, elegiría NodeJS JavaScript o Go si quisiera ejecutarlo a escala de Internet. Su huella de memoria es mucho menor que Java y su rendimiento es comparable al de Java.

Si su objetivo no es una escala muy grande, todo está bien. Mi favorito para aplicaciones de menor escala es Lucee, un derivado CFML basado en JVM que se encuentra en desarrollo activo. PHP, Ruby y Python también son buenas opciones.

Su base de conocimiento es Java, Java es multiplataforma, el talento de Java es omnipresente y Java tiene un largo historial de ejecución en numerosos entornos. ¿Por qué querrías usar algo más? ¿Mecanografía dinámica o interpretada? Esas pueden ser cosas buenas, pero ¿qué te dan al final? A menos que use algunos servicios en la nube que tengan un idioma preferido, no veo el caso para usar otra cosa.

Sí, debería, ya que la mayoría de ustedes conocen Java. Creo que comenzar su inicio con algo que ya sabía es una buena decisión, por lo que puede construir el prototipo más rápido, lanzar su producto al mercado e iterar más rápido.

Usaría con lo que se sienta cómodo y lo que se adapte al proyecto.

Java es de uso general y probablemente se adapte a lo que está haciendo, pero solo usted conoce los detalles de lo que debe hacer.

Creo que Java es un gran lenguaje, y obviamente está muy probado en el campo. Si ya lo sabe, no hay razón para no quedarse con él, suponiendo que se ajuste a su proyecto.

Yo diría ambos. Comience con Java como back-end, pero aún así necesitaría un lenguaje moderno para ponerse al día con las ventajas y no quiere quedarse atrás en la carrera de construir un back-end escalable y optimizado.