¿Según qué criterios técnicos elige un marco de back-end web en lugar de otro?

Aquí está mi árbol de decisión actual:

  • Lo que el cliente ya tenga
  • Lo que el cliente insiste en tener
  • Primavera

Pero todo lo dicho, siento el gran cambio en su camino que es ‘sin servidor’

Estoy experimentando con la sustitución de un sitio de pago de WordPress, en un servidor back-end, con tecnología AWS. Usando Lambda en lugar de un servidor. Cognito en lugar de un marco de inicio de sesión. S3 en lugar de un servidor web.

Hasta ahora, parece que se acabó el juego para los servidores de back-end para muchos casos de uso. Estoy realmente interesado en cómo se desarrolla esto, tanto para mí como en general.

Incluso en un compromiso de cliente que paga actualmente con una gran implementación de Dropwizard / Jetty / Java, puedo ver que en realidad no necesita una aplicación web de fondo. Solo un montón de llamadas a las API … que podrían ser sin servidor.

Interesante.

  1. ¿Qué idiomas tiene actualmente mi equipo como conjunto de habilidades? Utilice un marco de trabajo que sea nativo de ese idioma (por lo tanto, cuando sea inevitable que haya problemas en el marco, podemos resolverlos rápidamente).
  2. Soy el equipo Ok, entonces Slim Framework es mi primera opción. Este marco es muy estable, liviano, RESTful y está escrito en un lenguaje que soy muy hábil en usar.
  3. Por alguna razón, 1 o 2 no son opciones (el cliente o la empresa insiste en que use la plataforma Windows, por ejemplo). En parte por despecho y en parte porque soy experto en C # y sé cómo ejecutar y administrar un servidor IIS, desarrollaría mi propia solución de back-end.

Los criterios cambian caso por caso. Cada vez que recomiendo un nuevo marco (de cualquier tipo), me concentro en el ROI. En algunos casos, es más efectivo usar un nuevo marco. A veces es más efectivo usar algo familiar. Hay tantas variaciones de esto que puede ser vertiginoso, así que mantengo mis criterios de “alto nivel” simples:

  1. ¿Resuelve el problema?
  2. ¿Cómo posiciona el proyecto para el futuro? (cual es la trayectoria)
  3. ¿Cuánto tiempo costará?

Cualquier cosa que responda a esas tres preguntas, la mejor generalmente recibe mi aprobación.

Para cualquier cosa relacionada con la programación, uso lo que sé a menos que haya una mejor manera de hacerlo o haya una solución mucho mejor.

Me gusta Rails porque estoy familiarizado con Ruby y proporciona todo lo que necesito, pero es bastante complejo para una persona estar a cargo de todo, así que lo guardo para cuando estoy trabajando con un equipo o haciendo algo pequeño.

Cuando busco una mejor solución para cualquier lenguaje o marco, me hago estas preguntas:

  1. ¿Tengo que aprender un nuevo idioma para usarlo?
  2. ¿Cuáles son los riesgos / beneficios?
  3. ¿Se basa en una API?
  4. ¿Sería capaz de trabajar menos para una mayor eficiencia?
  5. ¿Qué puedo hacer con este lenguaje / marco que no puedo con lo que ya sé?

Hay algunas preguntas más dependiendo de lo que estoy tratando de hacer, pero esas son las principales.

¡Buena suerte!

El backend requiere más confianza y fiabilidad, así que elijo algo más antiguo y más establecido. Los clientes cambian todo el tiempo: ¡los componentes web son nativos en Safari y Chrome ahora! Pueden hacer cosas locas junto con sus usuarios y veremos qué sucede.

  • ¿Se ajusta a mi necesidad?
  • ¿Viene con muchos extras que no necesito?
  • ¿Hay mucha documentación?
  • ¿Hay tutoriales?
  • ¿Hay informes sobre conflictos con otras herramientas / marcos / versiones?

Si hay varios que encajan, entonces les doy una vuelta y elijo el más divertido.