2 रेल अनुप्रयोगों को एक कोडबेस

Question

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

कुछ मामलों में हम जवाहरात है कि यह कार्यक्षमता के कुछ हिस्सा में लेकिन यह जावास्क्रिप्ट, सीएसएस आदि में गहरे लाल रंग का परे चला जाता है ..

तो मैं एक codebase में इन दो क्षुधा विलय करने का काम सौंपा कर रहा हूँ। मुझे लगता है कि अंत में हम अनुमति आधारित भूमिका पहुंच के साथ एक एकल ऐप बनना चाहते हैं लेकिन यह बाद में आएगा।

मेरा पहला विचार है कि उन्हें जल्दी से एक साथ रखा जाए, दो रेल इंजन बनाने और उनके बीच सामान्य libs साझा करना है। मुझे लगता है कि कोड को गठबंधन करने, सामान्य अनुभाग ढूंढने और साझा करना शुरू करने का यह सबसे तेज़ तरीका है।

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

या, यदि किसी के पास इन ऐप्स को गठबंधन करने के तरीके के रूप में अन्य सुझाव हैं तो मैं सभी कान हूं।

वे दोनों रेल 2.3.10 क्षुधा JRuby 1.5.3 चल रहा है, लेकिन हम संभवतः Rails3 में अपग्रेड करने से है कि अगर चीजें काफी आसान या क्लीनर होगा खुला रहे हैं (यानी बेहतर रैक एकीकरण के साथ)

मैं किसी भी रैक प्रोग्रामिंग नहीं किया है, लेकिन यह जानने के लिए कभी दर्द नहीं होता है कि इससे हमारे जीवन को आसान बना दिया जाएगा।

Answer 1

इंजन का उपयोग करने का आपका विचार है जो मैं सुझाता हूं।

रूटिंग के लिए, मैं इसे रेल के बाहर संभाल दूंगा।

उदाहरण के लिए, आप क्या करेंगे nginx में निम्नलिखित:

server { 
    # Match only one host.              
    listen 80 default; 
    server_name YOUR_SINGLE_APP_DOMAIN; 

    location/{ 
     upstream YOUR_SINGLE_APP_RAILS; 
    } 
} 


server { 
    # Fall thru and match any other host.              
    listen 80 default; 
    server_name ~^.*$; 

    location/{ 
     upstream YOUR_MULTI_DOMAIN_APP_RAILS; 
    } 
} 

Answer 2

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

एक आवेदन के लिए पुन: लिखने की कार्यक्षमताओं के संबंध में, आधार के रूप में तैयार कोड के बड़े सेट के साथ उसको चुनें। यूआरएल पुनर्लेखन का समर्थन करने वाले वेब सर्वर का उपयोग करके प्रति विधि कोड माइग्रेट करना संभव होना चाहिए। मैंने mod_rewrite के साथ apache का उपयोग करने के बारे में सोचा। तो योजना होगी:

1. दोनों अनुप्रयोगों को एक अपाचे के माध्यम से सुलभ करने के लिए सेटअप करें।
2. एक विधि को चुनें जो दोनों में समान है और दोनों अनुप्रयोगों की आवश्यकताओं का समर्थन करने के लिए इसे एक एप्लिकेशन में फिर से लिखें।
3. अपाचे में केवल इस क्रिया पर एक एप्लिकेशन में यातायात को पुनर्निर्देशित करने के लिए एक mod_rewrite नियम जोड़ें।
4. सब कुछ फिर से लिखा जाने तक बिंदु दो पर जाएं।
5. वर्ष आवेदन निकालें और एक आवेदन

आप Apache का उपयोग करने की जरूरत नहीं है का उपयोग करने के मार्ग/mod_rewrite समायोजित, वहाँ URL पुनर्लेखन समर्थन अन्य वेब सर्वर होना चाहिए।

मैं रेलवे 3.0 पर हमारे आवेदन को फिर से लिखने के लिए इस एल्गोरिदम का उपयोग करने के बारे में सोच रहा था।