ruby on rails - phusion_passenger - Mejores prácticas para estructurar una aplicación ''grande'' de Rails
passenger rails app nginx (6)
Mi pregunta aquí es buscar las mejores prácticas, consejos generales y conocimientos, en lugar de una solución a un problema específico.
Estoy en las primeras etapas de planificación de un proyecto de Rails que considero bastante grande. En su nivel más simple, ofrece un CMS cortador de cookies a los usuarios objetivo. Así que los usuarios se registran y eligen un subdominio y reciben un sitio web bastante básico con CMS.
Por lo tanto, la aplicación completa tiene aproximadamente 4 ''lados'' diferentes:
- Un sitio web de ventas que vende el producto a usuarios finales: www.myapp.com
- Un área de administración central donde el personal puede iniciar sesión y administrar cuentas, etc. - www.myapp.com/superadmin
- Sitios web propios de los usuarios - subdominio.myapp.com
- El área de administración de usuarios / CMS - subdominio.myapp.com/admin
Lo que realmente busco es la mejor práctica para estructurar la aplicación. es decir, ¿todo debería integrarse en una gran aplicación o debería dividirse en 2 (o más) aplicaciones más pequeñas?
Si se implementa como una aplicación, puedo ver los problemas relacionados con el enrutamiento, ya que tanto el sitio web de ventas como los sitios web de los usuarios necesitarán una ruta de acceso raíz configurada, además, no querría que las rutas que configuré para el sitio web de ventas sean accesibles a través de los sitios web de los usuarios. ¿Se puede hacer algo dentro de Rails o en el nivel de Apache (reescritura de mod?) Para asegurar que no se mezclen las rutas?
Si se divide en 2 o más aplicaciones, ¿cómo hace que las aplicaciones compartan la misma base de datos? ¿Es eso incluso una buena idea? ¿Hay algún beneficio al dividir la aplicación (como aislar problemas en un área de la aplicación, en lugar de acabar con todo)?
Me doy cuenta de que esta publicación plantea muchas preguntas diferentes, pero agradezco cualquier consejo o idea que me puedan dar.
Agruparía todo esto en la misma aplicación porque no duplicarás las clases (modelos, complementos, etc.) en todas las aplicaciones. Además: ejecutar 4 aplicaciones significa que tendrás 4 procesos que consumirán memoria debido a las 4 pilas de Rails separadas que han cargado.
Compilarlo en una aplicación elimina este problema. Para el problema entre el sitio de ventas y el sitio de los usuarios, deben tener raíces diferentes que puedan resolverse, como se mencionó anteriormente , por subdomain_fu . Permítanme expandir con un código de ejemplo de una aplicación que tengo:
map.with_options :conditions => {:subdomain => ''logs''} do |admin|
admin.resources :channels do |channel|
channel.resources :logs
end
map.root :channels
map.connect '':id'', :controller => "channels", :action => "show"
end
Como vemos aquí, las :conditions para los with_options métodos with_options :subdomain son logs que significa que todo lo que ingrese a logs.mysite.com cumplirá con estas condiciones y, por lo tanto, se enrutará de esta manera.
Ahora más adelante en este archivo de enrutamiento tengo todo lo demás envuelto en un bloque similar:
map.with_options :conditions => {:subdomain => nil} do |admin|
# shebang!
end
Todo lo que vaya a mysite.com irá a estas rutas.
Por último, compilarlo todo en una mega-super-hiper-aplicación eliminará los problemas de intercambio de bases de datos.
Bueno, dado que nadie más ha hablado, lo invito a leer algo sobre Arquitectura Orientada a Servicios. El libro Enterprise Rails de Dan Chak tiene un gran material sobre este tema, y puede leerlo a través de Google Books. Prueba el capítulo 13, here. Creo que te pondrá en el camino correcto.
Creo que los beneficios de aislar sus preocupaciones en aplicaciones separadas superan los costos. Probablemente comenzaría con solo 2 aplicaciones (una para el sitio principal y superadmin, una para los sitios de clientes y administradores), accediendo a la misma base de datos, pero podría hacer 4.
La desventaja es que realmente no tiene aislamiento, ya que todas sus aplicaciones están vinculadas a una base de datos. Eventualmente se encontrará con problemas de escalado en su base de datos, pero si comienza de manera simple con una base de datos, lo iniciará. Una estrategia para escalar más tarde sería agregar una base de datos esclava que usan las aplicaciones del sitio cliente y del sitio principal, mientras que las aplicaciones de administración usan la base de datos maestra. Esto, junto con un montón de almacenamiento en caché te llevará bastante lejos.
No hay nada de malo en tener múltiples aplicaciones de rieles para acceder a una base de datos, sin embargo, necesitará una forma de compartir código común entre sus aplicaciones. Sus modelos en su mayor parte. Lo he hecho antes lanzando todos mis modelos en un complemento que comparto como un submódulo en git o como externo en svn. Tener aplicaciones separadas hará que cada aplicación sea más pequeña y más fácil de mantener.
Sin embargo, ¿dónde guardas tus migraciones? ¿Dónde pruebas tus modelos? Yo optaría por la aplicación superadmin. Además, realiza un cambio en un modelo o esquema, ¡y ahora tiene que verificar 2-4 aplicaciones y asegurarse de que aún funcionan!
Mejor aislamiento, db''s separados y comunicación entre aplicaciones a través de las API web (SOA) y no tiene que preocuparse por eso. SOA Creo que es el camino a seguir después de cierto punto, pero SOA puede ser prematuro cuando empiezas por primera vez.
En cualquier caso, tener aplicaciones separadas lo configura para SOA, pero no tiene que saltar más allá de un solo db para comenzar.
El mayor problema que veo al separarse en varias aplicaciones es que pierdes flexibilidad. ¿Qué sucede si, en el futuro, una tarea administrativa previa (por ejemplo, cargar un tipo de archivo) se convierte en una "tarea del usuario"? Tendrías que mover el código de una aplicación a la otra.
Mantendría todo en una sola aplicación y usaría roles para filtrar lo que cada usuario puede ver y hacer. Puede ser un poco más difícil al principio, pero se paga en un futuro cercano.
Eche un vistazo a los marcos de autorización, como declarative_authorization o cancan .
Veo que el tipo de problema al que te enfrentas es tratar de crear una aplicación que tendrá varios subdominios, por lo que account_manager un complemento puede resolver tu problema.
Además, si su aplicación es lo suficientemente grande como para mantenerla, sería buena idea dividirla en dos o tres, con recursos completos puede hacer que sus aplicaciones se comuniquen entre sí, y así.
mientras que si está pensando en tenerlos bajo una base de datos, eso es bastante simple en los rieles utilizando la conexión de establecimiento.
Creo que puede dividir la aplicación en tres o cuatro aplicaciones diferentes donde el conjunto de clústeres manejará cada solicitud de aplicaciones, por lo que la velocidad será buena. También puede agrupar una funcionalidad similar en una aplicación para asegurarse de que mantenerla sea fácil.