I don't think that 'un-rails-like' is necessarily a bad thing, to be honest. Your pain points there sound rather like getting past the point of Rails conventions and needing a new paradigm, which you've recognised. One thing I like about the hexagonal Rails approach that Matt Wynne has been going on about is that its a way of thinking about a much more modularised way of developing (and testing) rails apps. It's not SOA, but SOA leads pretty easily and naturally from it. And it really nicely controls your dependencies (and makes you think about and control your dependencies, rather than let Rails include everything, which is *huge*!). There's probably a more elegant way of doing it, but currently I launch stub Rack apps to mock any services I need in my integration tests. And I create service objects/libraries to call those services, so that they can easily be stubbed and mocked for unit testing. The only thing missing there, potentially, is a meta-integration test, where maybe you want to test the whole, distributed stack, with real or staging instances? I've not got to the point of needing to do that, yet, but I imagine that cucumber could do that pretty easily. But before you distribute everything to its own app, the Hexagonal Rails approach would give you cleanly defined modules that could then much more easily be evolved out into separate services as the need arose. I've no idea if that's any help, either, but I can hope. :) Cheers, Doug.
On 21 January 2013 17:41, Francis Fish <[email protected]> wrote: > 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. > -- 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.
