Por lo general, no hago A2A anónimo, pero a juzgar por su pregunta, puedo ver que hay cierta confusión en cuanto al propósito y la efectividad de los marcos y me gustaría ayudar a aclarar las cosas.
Sobre la pregunta 1
Todos los marcos establecidos tendrán comunidades activas durante años. Si hay algo que no debes temer, es un marco que se está volviendo obsoleto. Incluso algo tan desactualizado como CodeIgniter todavía tiene una base de usuarios increíblemente activa y se mantiene, a pesar de ser completamente innecesario durante años. Sin embargo, sus apuestas más seguras son los siguientes marcos y sus versiones:
- Symfony 2.7
- Symfony 2.8
- Sílex
- Laravel 5.1
- Lumen (derivación de Laravel 5.1)
- Phalcon 2.1
Estos tienen las comunidades más grandes y el soporte a largo plazo de sus desarrolladores. Otros marcos son proyectos de pasatiempo o no merece la pena prestarles atención.
- ¿Cuál es el próximo gran servicio web?
- ¿Cómo resuelven las startups web el problema del huevo y la gallina de tener contenido inicial antes de un lanzamiento público, si la aplicación web se basa completamente en contenido generado por el usuario?
- Cómo estimar el alcance del trabajo en la web y las aplicaciones más rápido
- Al implementar un sitio web / aplicación web, ¿debo colocar la aplicación y la API en el mismo servidor?
- ¿Cuáles son los flujos de trabajo óptimos para implementar la aplicación web?
De estas 5 instancias, Phalcon, Silex y Lumen son las mejores opciones para su caso de uso de desarrollar una API porque son las más livianas, aunque técnicamente, cualquiera de ellas lo hará. Si se está preguntando, Phalcon es el más rápido, pero eso es solo porque está instalado como una extensión PHP, no como un paquete PHP normal.
Para resumir el punto 1, las posibilidades de que el marco que elija se vuelva obsoleto en un corto período de tiempo son cero o casi cero.
Sobre la pregunta 2
No extiende un marco extendiendo el marco . Lo hace desarrollando servicios y clases en torno a los propósitos de su aplicación , y utilizando esos servicios dentro de su aplicación, independientemente del marco. Debe dejar de pensar en un marco como algo que aprisiona su aplicación; un marco está ahí para ayudarlo, no para encerrarlo en una forma específica de desarrollo . Por lo tanto, agregar funciones (correctamente) no es un problema y no genera problemas negativos, a menos que haga algo muy incorrecto.
Sobre la pregunta 3
Un marco puede perjudicarte si eres víctima de sus métodos de acceso directo. Por ejemplo, Laravel tiene algunos métodos auxiliares sin espacio de nombres de nivel raíz que se parecen a los métodos PHP nativos. Por ejemplo, vea estos: Funciones de ayuda: todos parecen estar integrados en PHP, cuando en realidad no lo están.
Al usar un marco como Laravel, puede caer en la trampa de usar estos métodos dentro de sus servicios (que pueden estar diseñados independientemente de la aplicación y su propósito) porque están universalmente disponibles en todas partes, y cuando intenta exportar su servicio / class en otra aplicación, u otro marco más adelante, encontrará que ya no funciona porque depende de los métodos auxiliares del marco anterior.
Esto generalmente se puede evitar si no le importa este “bloqueo de proveedor” o si desarrolla cuidadosamente sus cosas para que no dependan de la funcionalidad interna del marco.
Para resumirlo todo, no piense en un marco como algo que lo encierra. Un marco es, en la mayoría de los casos, simplemente una forma de pasar de una solicitud a su aplicación, y luego de su aplicación a una respuesta. Desarrolle sus servicios como independientes del marco, y estará bien incluso si el marco que ha elegido desaparece de la faz de la Tierra al día siguiente.
También recomendaría el libro de Phil Sturgeon: Creación de API que no odiarás. Aquí está mi crítica: Creación de API que no odiarás: revisión
¡Buena suerte!
