È possibile utilizzare Discourse come uno dei componenti di una più ampia applicazione Rails?
I miei obiettivi:
Condividere il database. Mi piacerebbe che la mia applicazione Rails utilizzasse lo stesso database di Discourse.
Condividere il login: sarebbe ottimo poter utilizzare il sistema di login di Discourse e riutilizzare il cookie di sessione per autenticare gli utenti in diverse parti della mia applicazione.
Aggiungere un insieme di nuove rotte ai miei componenti.
Bonus: personalizzare i view helper di Discourse che indirizzano gli utenti autenticati verso questi componenti aggiuntivi (forse è qualcosa che posso fare solo tramite le impostazioni, ma mi chiedo se esistano helper di Rails sovrascrivibili da utilizzare per personalizzare le informazioni a livello di sito).
Ho visto il post sull’uso di HAProxy per mettere Discourse dietro un proxy e instradare a un percorso di un dominio. Questo non è ciò che voglio, perché mi piacerebbe evitare di duplicare il framework Rails in un’altra applicazione (e non sono sicuro di quanto facilmente potrei riutilizzare la sessione utente in un’altra applicazione). È possibile utilizzare Discourse come componente in un’applicazione Rails più grande?
Non sono nemmeno sicuro che sia possibile farlo, ma anche se lo fosse, non è necessariamente consigliabile.
La tua installazione non potrà mai essere supportata dalla nostra comunità, poiché sarebbe troppo personalizzata.
Dovresti essere responsabile dell’integrazione di eventuali modifiche a Discourse. Al ritmo con cui apportiamo commit al repository, questo potrebbe significare un enorme lavoro per te, a seconda di cosa modifichi.
Puoi in qualche modo farlo già con SSO. Questo è un approccio più raccomandato per questo tipo di situazione.
È fantastico. Sono contento di sapere in anticipo che questa non è una cosa consigliata, così mi evito il problema di provarci e fallire miseramente!
Ok. Sembra che il modo migliore sia utilizzare due applicazioni Rails (Discourse e la mia app personalizzata) dietro un reverse proxy.
Dopo averci pensato, sembra che mantenere due database qui sia un’opzione migliore per assicurarmi che la mia app non aggiorni il database di Discourse in modo errato, come gli autori di Discourse non hanno mai previsto.
Hmmm, sarei meno pessimista. Si potrebbe anche dire che questo potrebbe essere un plugin molto grande.
Il plugin Custom Wizard è così grande che è quasi un’app separata (specialmente sul front-end).
C’è molta roba generica utile già integrata in Discourse che puoi riutilizzare, ad esempio il framework e le funzionalità degli account utente, la pipeline di distribuzione, ecc.
Inoltre, puoi adattare molti casi d’uso a Discourse sul front-end. I topic sono le tue pagine, ecc.
Qui, a mio avviso, il diavolo si nasconde nei dettagli.
Vantaggi dell’avere un’app separata: possiamo supportarvi meglio qui, e qualsiasi aggiornamento di Discourse non romperà la vostra parte dell’app.
Vantaggi dell’avere il sito come un “grande plugin Discourse”: ottenete tutte le funzionalità avanzate e gli strumenti disponibili in Discourse (inclusa tutta la gestione degli utenti), il che non è da sottovalutare.
Sarebbe interessante a seconda di cosa state costruendo: penso che @justin voglia mettervi in guardia dai potenziali oneri di manutenzione che vi assumete. Non possiamo supportarvi pienamente se state costruendo direttamente sopra Discourse, e tutti i nostri helper e schemi interni sono soggetti a modifiche ™, quindi potrebbe essere più problematico di quanto valga la pena. (A seconda di cosa state costruendo, naturalmente! Potrebbe anche essere facilmente un investimento che vale la pena )
Sì, è assolutamente vero. Servono esperienza per scrivere plugin robusti rispetto ai cambiamenti del core. Dovrai evolvere alcuni elementi dell’app per stare al passo con i cambiamenti di Discourse. Ma è fattibile.
Ho dato un’occhiata rapida ai plugin. Preferisco utilizzare un framework JS diverso da Ember (sono un fanboy di Svelte) e sono un po’ preoccupato che questo aggiunga un livello o un’interfaccia all’app Rails di Discourse (con cui non sono familiare), rendendo la risoluzione dei problemi più complessa per me. Sto propendendo per mantenere questo come un’app separata. Conosco bene Rails (e il proxying delle app Rails), ma non conosco ancora Discourse e sento che avrò meno ostacoli se seguirò questa strada.
)