¿Es posible usar Discourse como un componente de una aplicación Rails más grande?
Mis objetivos:
Compartir la base de datos. Me encantaría que mi aplicación Rails utilice la misma base de datos que usa Discourse.
Compartir el inicio de sesión: sería ideal poder usar el sistema de inicio de sesión de Discourse y reutilizar la cookie de sesión para autenticar a los usuarios en diferentes partes de mi aplicación.
Agregar varias rutas nuevas a mis componentes.
Bonus: personalizar los helpers de vistas de Discourse que dirigen a los usuarios registrados a esos componentes adicionales (¿quizás esto se pueda hacer solo mediante configuraciones, pero me pregunto si hay helpers de Rails que se puedan sobrescribir para personalizar la información de todo el sitio)?
Vi la publicación sobre el uso de HAProxy para colocar Discourse detrás de un proxy y enrutarlo a una ruta en un dominio. Esto no es lo que quiero, porque me encantaría evitar duplicar el framework de Rails en otra aplicación (y no estoy seguro de qué tan fácilmente podría reutilizar la sesión de usuario en otra aplicación). ¿Es posible usar Discourse como un componente en una aplicación Rails más grande?
Ni siquiera estoy seguro de que sea posible hacer esto, pero si lo fuera, no necesariamente sería recomendable.
Tu instalación nunca será compatible con nuestra comunidad, ya que sería demasiado personalizada.
Tendrías que ser responsable de fusionar cualquier cambio en Discourse. A la velocidad con la que hacemos commits al repositorio, esto podría significar un montón de trabajo para ti, dependiendo de lo que modifiques.
Ya puedes hacer algo similar con SSO. Esa es una aproximación más recomendada para este tipo de cosas.
¡Eso es genial! Me alegra saber de antemano que esto no es algo recomendado; así me ahorro el problema de intentarlo y fracasar estrepitosamente.
Vale. Suena a que la mejor opción es usar dos aplicaciones de Rails (Discourse y mi aplicación personalizada) detrás de un proxy inverso.
Tras pensarlo, parece que mantener dos bases de datos aquí es una mejor opción para asegurarme de que mi aplicación no actualice la base de datos de Discourse de una manera que los autores de Discourse nunca tuvieron la intención.
Hmm, yo sería menos pesimista. También podrías decir que esto podría ser un plugin muy grande.
El plugin Custom Wizard es tan grande que casi es una aplicación independiente (especialmente en el front end).
Hay muchas cosas genéricas útiles escritas en Discourse que puedes reutilizar, como el marco y la funcionalidad de cuentas de usuario, el pipeline de implementación, etc.
Además, puedes adaptar muchos casos de uso a Discourse en el front end. Los temas son tus páginas, etc.
Ventajas de tener una aplicación separada: podemos brindarte un mejor soporte aquí, y cualquier actualización de Discourse no afectará el lado de tu aplicación.
Ventajas de que el sitio sea un “gran complemento de Discourse”: obtienes todas las funciones avanzadas y asistentes disponibles en Discourse (incluida toda la gestión de usuarios), lo cual no debe subestimarse.
Sería genial, dependiendo de lo que estés construyendo. Creo que @justin quiere advertirte sobre la posible carga de mantenimiento que asumirás. No podemos ofrecerte un soporte completo si estás construyendo directamente sobre Discourse, y todos nuestros asistentes y esquemas internos están sujetos a cambios ™, por lo que podría darte más problemas de los que vale la pena. (¡Dependiendo de lo que estés construyendo, por supuesto! También podría valer la pena el esfuerzo fácilmente ;))
Sí, eso es muy cierto. Se necesita experiencia para escribir plugins que sean resistentes a los cambios del núcleo. Tendrás que evolucionar algunos elementos de la aplicación para mantener el ritmo con los cambios en Discourse. Pero se puede hacer.
He echado un vistazo rápido a los plugins. Prefiero usar un framework JS distinto a Ember (soy fan de Svelte) y me preocupa que esto añada una capa o interfaz a la aplicación Rails de Discourse (con la que no estoy familiarizado), lo que complicaría más el diagnóstico de problemas para mí. Me inclino por mantenerlo como una aplicación independiente. Conozco bastante bien Rails (y cómo hacer proxy de aplicaciones Rails), pero aún no conozco Discourse, y siento que tendré menos obstáculos si sigo esta ruta.