Nuestro desarrollador sugiere Python para la API: ¿es una opción segura o solo por costumbre?

Usando estructuras asíncronas modernas en Python, no vais a tener cuellos de botella en transferencias de datos basadas en I/O. Aunque el tráfico de una plataforma B2B alcance decenas de miles de peticiones por minuto, si los índices de la base de datos están bien hechos, la carga real recae en la base de datos, no en el lenguaje. No os preocupéis.

En nuestra propia plataforma de logística de e-commerce gestionamos 1,5 millones de llamadas a la API al día con microservicios en Python. El servidor en la nube no nos cuesta más de 65 dólares al mes. No os creáis el mito de que el lenguaje es lento, la factura cara viene de una mala arquitectura.

La preferencia del dev importa, pero ¿qué pasa si mañana se va del proyecto? Aunque hay mucha gente que sabe Python, no cualquiera te escribe arquitectura asíncrona limpia. Aseguraros bien de que el proyecto quede estructurado por capas y con tipado estático, si no el traspaso va a ser una pesadilla total.

Haga incluir estos 3 requisitos técnicos en el contrato: 1) Documentación de todos los endpoints con esquema estándar OpenAPI. 2) Uso completo de type hints. 3) Cobertura de pruebas unitarias de al menos el 70 por ciento para los escenarios principales. Mientras se cumplan estas tres condiciones, Python no dejará riesgos a futuro.

por la legibilidad del codigo python es una excelente opcion. si mas adelante meten a un programador nuevo al equipo no le toma mas de unos dias entender el proyecto. con lenguajes mas complejos eso lleva semanas.

Independientemente de la arquitectura de software elegida, le recomiendo dejar bien claras las cláusulas de propiedad intelectual y titularidad del código. Que el código fuente se mantenga en un repositorio privado de su empresa y que se revisen las licencias de las dependencias de terceros es fundamental para su seguridad jurídica.

Hágale una sola pregunta a su desarrollador: '¿Qué arquitectura y framework asíncrono vas a usar y cómo vas a gestionar el pool de conexiones a la base de datos?' Si responde sin dudar y con argumentos técnicos claros, puede avanzar con confianza.

Hace tres años, en la plataforma que fundé, elegimos un sistema súper nicho por sugerencia del equipo porque 'iba a ser rapidísimo'. A los seis meses se fue el programador principal y no encontramos a nadie más que supiera ese lenguaje. Al final tuvimos que rehacer todo desde cero con Python y recién ahí respiramos tranquilos.

Os cuento lo que me pasó a mí, a ver si os sirve de ayuda. Todos los que se apresuran con desarrollo de API se atascan en el mismo punto.

Lo escribo para que no cometan el mismo error. Intentar hacerlo solo es la vía más cara.

Antes de decidir, mirad qué datos tenéis en la mano. Espero que le sea útil.

Soy una pequeña empresa, os lo cuento desde mi lado. La gente no defiende el proceso defiende la costumbre. La resistencia viene de ahí.

Ánimo.

Tema muy oportuno.

Creo que este consejo no sirve para todos. La oferta más barata suele ser la menos pensada.

Espero que le sea útil.

La discusión se ha dispersado, voy a ordenarla. Si es la primera vez que lo hacéis, empezad poco a poco, la escala llegará después.

Si escribís el resultado aquí, también servirá de ayuda a otros.

en este punto no estoy de acuerdo con ustedes. si es la primera vez que lo hacéis, empezad poco a poco la escala llegará después.

por supuesto, cambia si tu situación es diferente.

Os explico cómo se hace en la práctica. En un sistema heredado, lo más caro son las dependencias desconocidas.

Eso es todo, disculpa si me he extendido demasiado.

Voy a resumir el tema porque se han dado varias respuestas diferentes. En un sistema heredado lo más caro son las dependencias desconocidas.

Si no lo pones por escrito desde el principio, luego surgen discusiones. Lo dejo como nota, por si sirve.

Buen trabajo.