कई अनुप्रयोगों के लिए फीनिक्स छतरी ढांचे को कैसे बनाया जाए

Question

मैं phx 1.3 और छतरी ऐप्स का उपयोग कर उत्पादों के एक नए सूट के लिए एक आर्किटेक्चर के साथ खेल रहा हूं।

मेरे पास मौजूदा फीनिक्स आधारित एंटरप्राइज़ क्लास वेबआरटीसी सॉफ्ट फोन (कई चाबियाँ, एक डिस्प्ले, एकाधिक इनपुट और आउटपुट ऑडियो डिवाइस चयन, आदि) हैं। मैंने फीनिक्स के साथ एक स्लैक क्लोन मैसेजिंग ऐप प्रोटोटाइप विकसित किया है। दोनों एप्लिकेशन काफी बड़े हैं मुझे चैट एप के साथ फोन को एक फ्रंट एंड में एकीकृत करने की आवश्यकता है जो कि सिर्फ फोन, बस चैट क्लाइंट और दोनों हो सकता है। मुझे चैट क्लाइंट को आगे बढ़ने के लिए बहुत सी नई सुविधाएं जोड़ने की आवश्यकता होगी, मैं भी कॉल क्लाइंट (उपयोगकर्ता आधारित) पर अतिरिक्त सेटिंग प्रावधान करने के लिए आर्किटेक्चर का समर्थन करना चाहता हूं और संभावित रूप से बड़ी संख्या में व्यवस्थापक स्तर सेटिंग्स । मैं भविष्य में अन्य ऑपरेटर पैनल, लॉग व्यूअर जैसे अन्य एप्लिकेशन भी जोड़ सकता हूं, और सूची जारी है ... क्लाइंट साइड जेएस बहुत आसान है, कोई फ्रंट एंड फ्रेमवर्क नहीं है। मैं टेम्पलेट सर्वर पक्ष प्रस्तुत करता हूं और चैनलों पर एचटीएमएल को धक्का देता हूं।

मैं इस प्लग को बनाना चाहता हूं। वही एंडपॉइंट और डेटाबेस। एक आम यूएक्स।

मुझे लगता है कि छतरी में दो आम ऐप्स होंगे, एक फीनिक्स एंडपॉइंट और एक जोड़े नियंत्रकों के लिए और दूसरा मुख्य रेपो और कुछ स्कीमा के लिए होगा। मैं यह पता लगाने की कोशिश कर रहा हूं कि प्रत्येक एप्लिकेशन के लिए दो या दो से अधिक अतिरिक्त ऐप्स का उपयोग करना कितना मुश्किल होगा। संदर्भ और स्कीमा के लिए एक, नियंत्रक, विचार, टेम्पलेट्स और ब्रंच संसाधन के लिए दूसरा। शायद तीसरे पक्ष के एपीआई के लिए एक और।

यह काम करने के लिए, मुझे प्रत्येक ऐप्स में राउटर के लिए गतिशील प्रेषण की आवश्यकता होगी। प्रत्येक ऐप में मौजूद माइग्रेशन को संभालने के लिए एक विधि, और शायद अधिक मैंने अभी तक नहीं सोचा है।

किसी ने भी यह कोशिश की? क्या ऐसी ही संरचना के साथ कोई खुली स्रोत परियोजनाएं हैं?

Answer 1

दिन-प्रतिदिन काम करने वाले एलीक्सिर ऐप 13 ऐप्स के साथ छतरी है।

रूट पर फीनिक्स एंडपॉइंट और शीर्ष स्तर राउटर है जो आगे के अन्य ऐप्स में परिभाषित रूटर से अनुरोध करता है।

इसका मतलब है कि ऐप परतों (वेब ​​/ व्यवसाय/डेटा) में विभाजित नहीं है बल्कि लंबवत डोमेन स्लाइस में विभाजित है।

यह पिछले 12 महीनों में ऐप में काफी वृद्धि हुई है क्योंकि यह अच्छी तरह से बढ़ गया है।

सबसे बड़ी पकड़ लिया मैं मिला है कि फीनिक्स रूटर अनुरोध पर ले जाने वाले पथ पट्टी जब दूसरे रूटर्स को अग्रेषण है, इसलिए हम बनाया एक mountPlug रूटर जो अनुरोध पथ अपरिवर्तित रहता है के साथ उपयोग करने के लिए मैक्रो:

defmodule MyApp.Router do 
    @moduledoc """ 
    Top level routing to each of the sub-systems 
    """ 

    use Plug.Router 

    plug :match 
    plug :dispatch 

    mount "/events/*_", Events.Router 
    mount "/report/*_", Report.Router 
    mount "/stats/*_", Stats.Router 
    mount "/auth/*_", Auth.Router 
end 

और माउंट:

defmacro mount(path, router, opts \\ []) do 
    quote do 
    @opts unquote(router).init(unquote(opts)) 
    match unquote(path), do: unquote(router).call(var!(conn), @opts) 
    end 
end 

हम सिर्फ सादगी के लिए एक ही ऐप्लिकेशन में पूरे डेटाबेस के प्रवास का प्रबंधन, लेकिन Ecto स्कीमा प्रत्येक अनुप्रयोग में अलग से घोषित किया गया है।

Here एक ऐसी परियोजना है जो कुछ अवधारणाओं को प्रदर्शित करती है।

Answer 2

मैं भी काफी छतरी आवेदन पर काम कर रहा हूं।प्रत्येक ऐप में कॉन्फ़िगर किए गए एंट्री पॉइंट्स वाली फ़ाइल को बनाए रखने के बजाय मैं देखना चाहता था कि मैं इसे और अधिक गतिशील बना सकता हूं या नहीं। इसलिए मैंने एक प्लग लिखा जो इस तरह दिखता है:

def call(%{path_info: [path|_]} = conn, opts) do 
    path = path |> String.downcase() |> Macro.camelize() 
    module = 
    try do 
     Module.safe_concat [LocationRouting, path, Location] 
    rescue 
     _ -> nil 
    end 
    if module do 
    module.call(conn, opts) 
    else 
    conn 
    end 
end 

मैंने अंत में प्लग को जोड़ा। और फिर यह Plug.Builder

का उपयोग करके बुलाया मॉड्यूल जो एक रूटर या कि समाप्ति बिंदु के समान कुछ जोड़ने की फिर से सक्षम है पर निर्भर है

पूर्ण उदाहरण यहाँ देख सकते हैं: https://github.com/tverlaan/location_routing