Hi Paul Sounds like a bad case of premature optimisation to me. There are some gems knocking around where you can record and replay responses from external API calls (not used them in an age so ... guys?) that may help you write some tests.
You could also look at folding it all back in but using the Rails 3 middleware stack. That might be less up front rewriting - but without seeing the app it's hard to say if it would be worth the hassle. I was listening to the Ruby Rogues Sandi Metz episode and she was saying that you can do things like identify the piece you need to change, turn off the old code, and do a functional replacement. As in, don't rewrite, but write it for the functionality revealed by the working app, using it as a spec. I did a lot of SOA work when it was new 10 or so years ago and it always seemed more trouble than it was worth, but we are talking Java/Oracle land where doing anything was pretty hard. When you need to scale, then you need to consider SOA. I wonder if it was cast that way for resilience? As in, you can gracefully replace failed pieces with sensible defaults and the site stays up, plus allow graceful degradation of service? There's also the 5 9's problem - the whole system's reliability becomes the product of the probability of failure for each component instead of just the most vulnerable piece and without that resilience architecture in place it hurts even more. Not sure if my rambling's been any help, but I'd rewrite or recast it all. You don't know where the pain is until you feel the pain. Before that it's mere speculation. Thanks and regards, Francis Follow me on twitter https://twitter.com/fjfish Blog at http://www.francisfish.com (you can also buy my books from there!) CV http://www.pharmarketeer.com/francis.html Comfort the frightened, coach the clueless and teach the uninformed. Seth Godin On Mon, Jan 21, 2013 at 3:23 PM, Paul Robinson <[email protected]> wrote: > 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. > > -- 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.
