Hi all, I'm asking NWRUG this despite being in London these days, because I know some of you might have dealt with similar setups. Oh, and I've been to far, far more NWRUG meets than I have LRUG. :-)
I'm currently trying to get my head around an app that has an architecture heavily inspired by this book: http://www.amazon.co.uk/Service-Oriented-Design-Rails-Addison-Wesley-Professional/dp/0321659368 It is implemented using https://github.com/typhoeus/typhoeus in various clients talking to several different JSON API endpoints provided by multiple Rails apps, and right now I'm feeling quite debilitating pain points around testing, adding new features quickly, deployment in the sense we have a lot of code to keep up in the air, etc. These are all pain points I feel would be avoided with a more "monolithic" app. I can fix them without changing the architecture, but it feels like there isn't a bigger picture issue going on here. I am torn. Clearly, SOA is the way to go if scaling is a major issue and we want to swap in/out components. However I am also a fan of convention over configuration and some of the hoops you jump through with Typhoeus feel incredibly unconventional and very un-Rails like. Un-Ruby like in some cases. Implementing a 20-30 line method that queues up API calls and then runs them in a threaded asynchronous fashion is very clever, it's just not the way I've trained myself to write code these days... I have a choice: 1. Collapse things back down into a more monolithic app. Almost all components are Rails with the need to talk to some third-party client applications via APIs which we could implement with some nested controllers off to the side of a conventional monolithic application 2. Realise it's unfamiliarity on my part and push through to a greater understanding of why this setup is so awesome and why what I think are code smells are in fact beautiful fragrant bouquets. 3. Perhaps push through on re-factoring what we have so that it's the same architecture but refactored code, smaller methods, etc., or perhaps start looking for other implementations that are "more Rails" like than what we have right now. I was wondering what your collective experiences were with SOA and if there was any best practice reading you might suggest, or indeed any comments/insights you've had on trying to get bigger SOA Rails apps dancing nicely. Thanks, Paul -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
