Ich spiele mit einer Architektur für eine neue Produktsuite mit phx 1.3 und Regenschirm-Apps.
Ich habe ein existierendes Phoenix-basiertes WebRTC-Telefon der Unternehmensklasse (viele Tasten, ein Display, mehrere Ein- und Ausgänge, Audiogeräte und mehr). Ich habe mit Phoenix einen Slack-Klon-Messaging-App-Prototyp entwickelt. Beide Anwendungen sind ziemlich groß Ich muss das Telefon mit der Chat-App in ein Frontend integrieren, das entweder nur das Telefon, nur der Chat-Client und beides sein kann. Ich muss dem Chat-Client eine Menge neuer Funktionen hinzufügen, die sich vorwärts bewegen Ich möchte auch, dass die Architektur die Verwendung desselben Clients unterstützt, um zusätzliche Einstellungen auf dem Anrufserver (benutzerbasiert) und möglicherweise eine große Anzahl von Einstellungen auf der Verwaltungsebene bereitzustellen. Ich könnte auch andere Anwendungen in der Zukunft hinzufügen, wie ein Bedienfeld, Log Viewer, und die Liste geht weiter ... Die Client-Seite JS ist ziemlich einfach, kein Front-End-Framework. Ich render Vorlagen Server-Seite und schieben Sie die HTML-out über Kanäle.
Ich möchte dieses Pluggable bauen. Derselbe Endpunkt und dieselbe Datenbank. Ein gemeinsames UX.
Ich denke, es wird zwei gebräuchliche Apps geben, eine für den Phoenix-Endpunkt und ein paar Controller und eine weitere für das Haupt-Repo und ein paar Schemata. Ich versuche herauszufinden, wie schwierig es ist, zwei oder mehr zusätzliche Apps für jede Anwendung zu verwenden. Eine für Kontext und Schema, eine weitere für Controller, Ansichten, Vorlagen und Brunch-Ressourcen. Möglicherweise ein anderes für APIs von Drittanbietern.
Damit das funktioniert, brauche ich einen dynamischen Versand für Router in jeder der Apps. Eine Methode zur Behandlung von Migrationen, die in jeder der Apps enthalten sind, und wahrscheinlich mehr, an die ich noch nicht gedacht habe.
Wie hat das jemand versucht? Gibt es Open-Source-Projekte mit ähnlicher Struktur?
Die Elixier-App, mit der ich täglich arbeite, ist ein Regenschirm mit 13 Apps.
Der root ist der Phoenix-Endpunkt und der Top-Level-Router, der Anfragen an Router weiterleitet, die in den anderen Apps definiert sind.
Dies bedeutet, dass die App nicht in Schichten (Web / Business / Daten) aufgeteilt wird, sondern in vertikale Domänenscheiben.
Dies ist gut skaliert, da die App in den letzten 12 Monaten deutlich gewachsen ist.
Der größte Fehler, den ich hatte, ist, dass Phoenix-Router den führenden Pfad von der Anfrage beim Weiterleiten an andere Router entfernen. Daher haben wir ein mount -Makro erstellt, das mit dem Plug -Router verwendet wird, der den Anfragepfad unverändert lässt:
und mount:
%Vor%Wir verwalten die Migrationen der gesamten Datenbank aus Gründen der Einfachheit in einer einzigen App, aber Ecto-Schemas werden in jeder App separat deklariert.
Hier ist ein Projekt, das einige der Konzepte demonstriert.
Ich arbeite auch an einer ziemlich großen Regenschirm-Anwendung. Anstatt eine Datei mit konfigurierten Einstiegspunkten für jede App zu verwalten, wollte ich sehen, ob ich sie dynamischer gestalten kann. Also habe ich einen Stecker geschrieben, der so aussieht:
%Vor% Ich habe diesen Stecker zum Endpunkt hinzugefügt. Und dann liegt es an dem aufgerufenen Modul, das wiederum einen Router oder etwas Ähnliches zu einem Endpunkt hinzufügen kann, indem Plug.Builder
Sie können das vollständige Beispiel hier ansehen: Ссылка
Tags und Links elixir phoenix-framework