Desarrollo en Laravel

Sí, y buena parte de nuestro trabajo en Laravel empieza así. Leemos el código, comprobamos las versiones del framework y de PHP y si siguen recibiendo correcciones, miramos la estructura y los tests, y atendemos primero lo urgente. Después recibe una descripción honesta de dónde está y un plan que pueda presupuestar. A veces ese plan es reconstruir. Normalmente no lo es.

Una versión mayor cada vez. PHP va primero cuando es lo que bloquea el framework, después Laravel, después los paquetes que lo mantenían anclado, con tests alrededor de las partes que importan antes de mover nada. Sigue en producción durante todo el proceso, y el trabajo puede pausarse entre versiones. Saltar directamente desde dos versiones atrás a la actual es posible, pero los cambios incompatibles de cada versión intermedia siguen aplicando, así que es el mismo trabajo con menos mapa.

Cada versión mayor recibe 18 meses de correcciones de errores y dos años de correcciones de seguridad desde su fecha de publicación, y cada año sale una nueva. En la práctica, la versión actual y la anterior son las únicas que reciben correcciones en un momento dado, y todo lo anterior no recibe nada. Ejecute php artisan --version, o lea la línea laravel/framework en composer.lock, para saber dónde está.

Para una aplicación a medida (un portal, una herramienta interna, una capa de integración, una API), normalmente sí. Trae las piezas que toda aplicación necesita, y muchos desarrolladores lo conocen, así que encontrar a alguien que trabaje en ella más adelante es una contratación normal. Para una tienda online, casi seguro que no: una plataforma de comercio lo hará mejor y a menor coste, y se lo diríamos. Para un sitio corporativo sencillo, un CMS suele encajar mejor.

Normalmente por una de una lista corta: consultas ejecutándose en un bucle (el problema N+1), un índice de base de datos que falta, una cache configurada pero que en realidad no cachea, trabajo hecho durante la petición que debería ir en una cola, o un servidor con menos margen del que necesita el tráfico. Medimos antes de cambiar nada, porque la parte lenta a menudo no es la que alguien sospecha.

Sí. Comprobamos la autenticación y el manejo de sesiones, si el doble factor está disponible para las cuentas que lo necesitan, la autorización en cada ruta que debería tenerla, cómo se trata lo que envían los usuarios de camino al panel de administración, las cabeceras de seguridad, las dependencias con vulnerabilidades conocidas y qué pasa con las copias de seguridad. Recibe una lista por escrito, ordenada por lo que hay que arreglar primero.

A menudo sí, y por etapas. Las funciones nuevas se construyen en Laravel junto al código antiguo, las rutas se mueven según se tocan, y los dos comparten una sola base de datos hasta que el lado antiguo queda vacío. El negocio sigue funcionando sobre la aplicación todo el tiempo. Si merece la pena depende de qué hace la aplicación antigua y de cómo está construida, que es lo primero que miramos.

Sí, y es una combinación habitual. La tienda se queda en Magento, y Laravel se encarga de lo que la plataforma nunca estuvo pensada para hacer: un portal de clientes con sus propias reglas, la capa de integración entre la tienda y un ERP o un sistema de almacén, una herramienta de informes, un panel interno. Trabajamos en los dos lados, así que los dos se diseñan juntos.

Cuando la interfaz lo pide. Muchas aplicaciones están mejor servidas con Blade y Livewire, que mantienen todo en un solo código y un solo lenguaje. Cuando una pantalla tiene que comportarse como una aplicación (filtrado en vivo, mucho estado, un editor) la construimos en React contra una API de Laravel. Este sitio es Laravel con páginas React prerrenderizadas a HTML estático.

Con una conversación sobre qué tiene que hacer la aplicación y dónde se rompe ahora mismo, y después un alcance por escrito que cubre qué entra, qué no, y qué construiríamos o arreglaríamos primero. Definimos el alcance antes de pedirle que se comprometa, y si creemos que el trabajo no nos necesita, se lo diremos.

Sí. Algunos clientes nos mantienen con un contrato de servicio continuo para actualizaciones de seguridad, de dependencias y del framework, monitorización y una cola de mejoras. Otros se llevan la aplicación a su equipo interno, que es para lo que están la documentación y los tests.

Sí. Emyrix tiene su sede en Massachusetts y trabaja de forma remota con empresas de todo Estados Unidos. Trabajamos en horario de EE. UU., usamos contratos estadounidenses y facturamos en dólares.