Un servicio web verifica permisos, modifica datos, calcula precios y se comunica con sistemas externos. Al sustituir PHP hay que conservar esas decisiones y los compromisos con las aplicaciones cliente. Elegir lenguaje es solo una parte. Primero definimos contratos API, reglas operativas y disponibilidad; después seleccionamos Go o Node.js y un alojamiento adecuado a la carga real.
Empezamos por los límites del servicio
Inventariamos peticiones entrantes y eventos salientes. Para cada escenario identificamos quién llama, qué datos envía y qué respuesta espera. Documentamos errores, límites de frecuencia y repeticiones. En aplicaciones antiguas estas reglas pueden existir solo en el código. Hacerlas explícitas evita modificar integraciones de socios sin avisar.
Crear un pedido exige más que devolver éxito y añadir una fila. Deben conservarse cálculo, relación con cliente y transiciones de estado. Repetir tras un fallo de red no debe crear otro pedido inesperadamente. Notificaciones y sincronización requieren control propio. Describimos el escenario completo del negocio, no solo el manejador de una ruta, para verificar su integridad.
Cuándo elegimos Go
Consideramos Go para lógica clara de servidor, peticiones concurrentes y despliegue controlado. Definimos módulos, base y errores con antelación. Compilar un ejecutable simplifica algunas entregas, pero no elimina configuración e infraestructura. Validamos la elección con un escenario representativo y mediciones reales, especialmente si sustituimos varios procesos por un servicio.
Cuándo elegimos Node.js
Node.js puede encajar si ayudan JavaScript en servidor, API externas y las capacidades del equipo. Los manejadores deben gestionar bien la asincronía y separar cálculos costosos. Elegimos una rama con soporte y fijamos dependencias. El catálogo de paquetes facilita integraciones, pero exige criterio: incorporar una biblioteca para una tarea mínima no siempre compensa su mantenimiento.
| Criterio | Go | Node.js |
|---|---|---|
| Equipo | Capacidad de mantener Go | Familiar para equipos JavaScript |
| Entrega | Aplicación compilada | Entorno de ejecución y dependencias |
| Integraciones | Verificar SDK necesarios | Verificar SDK necesarios |
| Despliegue | VPS, contenedores o funciones | VPS, contenedores o funciones |
Dónde alojar el servicio
Un VPS/VDS ofrece recursos persistentes y control del entorno. Los contenedores facilitan reproducibilidad con imagen y configuración preparadas. Serverless puede servir para carga variable o eventos con duración adecuada. Siempre quedan base, red, secretos y supervisión. Calculamos almacenamiento, tráfico y picos, en lugar de elegir por el precio anunciado de una invocación.
Las tareas de fondo importan tanto como el API público. Informes, boletines y sincronizaciones pueden ejecutarse por horario y pasar inadvertidos en una demostración. Inventariamos tareas, definimos reintentos y registramos resultados. Las operaciones con efectos requieren protección frente a duplicados, especialmente cuando colas o funciones pueden entregar eventos repetidamente.
- Contratos y reglas del negocio → Elegir Go o Node.js
- Elegir Go o Node.js → Verificar API y datos
- Verificar API y datos → Migrar tráfico por rutas
- Migrar tráfico por rutas → ¿Operaciones confirmadas?
- ¿Operaciones confirmadas? → Retirar el backend antiguo (Sí)
- ¿Operaciones confirmadas? → Verificar API y datos (No)
Mantener los compromisos durante la transición
Los servicios complejos pueden migrarse gradualmente tras una entrada común si se define propiedad de operaciones y escritura. Dos implementaciones no deben modificar independientemente una entidad sin coordinación. Primero trasladamos un escenario limitado, contrastamos resultados y ampliamos tráfico. Así aparecen incompatibilidades antes de afectar al producto completo.
La aceptación incluye peticiones correctas y fallidas. Probamos usuarios normales, administradores e intentos de acceso a datos ajenos. Importa el estado final, además del código HTTP. Los pagos utilizan pruebas del proveedor y una comprobación acordada del lanzamiento. Los registros deben localizar fallos sin exponer datos personales innecesarios. El resultado fundamenta el cambio y la retirada de PHP.
Un responsable por operación
Durante la migración gradual se establece qué sistema modifica un pedido o saldo. Compartir base no basta: cada implementación puede interpretar estados y repetir efectos de forma distinta. Asignamos escritura por etapa y documentamos su transferencia. A veces la lectura puede trasladarse antes, pero depende del modelo de datos.
Los clientes externos conservan una entrada estable o reciben un cambio de contrato acordado. Definimos mantenimiento sin mostrar errores internos al usuario. La compatibilidad temporal de API tiene plazo y condiciones de cierre. Debes saber qué sigue dependiendo de PHP y por qué, evitando mantener dos backends competidores indefinidamente.
Elegimos métricas antes del cambio: operaciones correctas, errores y tiempos de respuesta. Deben representar cargas equivalentes para decidir con fundamento cuánto tráfico trasladar.
La transición gradual necesita un final definido. Una ruta que permanece temporalmente en PHP puede formar parte del plan, pero debe tener finalidad, responsable y condición de retirada. Antes de apagarla se revisan API, tareas programadas y notificaciones externas. Evita declarar completa una migración que aún necesita un proceso antiguo para informes o estados de pedidos.
También se valora la operación cuando algo falla. Los registros deben permitir localizar la petición o el evento sin exponer datos personales innecesarios. La aceptación no se limita al código HTTP: se comprueba el estado final de la operación y el comportamiento para distintos roles.
El presupuesto incluye los recursos que realmente utiliza el servicio. Un proceso barato no representa todo el coste si almacenamiento, tráfico y supervisión se pagan aparte. Esta información permite elegir VPS, contenedores o funciones con conocimiento de la carga y de las responsabilidades posteriores.
Qué recibe el cliente
Un servicio con contratos documentados, datos migrados y publicación reproducible. Entregamos código e instrucciones y definimos copias y responsables de infraestructura. Las nuevas integraciones se valoran por módulos claros. Envía API, conexiones y carga: prepararemos arquitectura, costes y plazo según la complejidad real.
Fuentes
Node.js: versiones y soporte. Go: gestión de vulnerabilidades. AWS Lambda: recomendaciones operativas. Revisado el 26 de octubre de 2026. Los procedimientos, ejemplos, precios y plazos describen el servicio propuesto por el proyecto.
