On Thursday, November 14, 2013 10:50:48 AM UTC-8, Jonathan Irving wrote: > > * Brian Craft <craft...@gmail.com <javascript:>> [2013-11-14 10:24 > -0800]: > > On Thursday, November 14, 2013 9:42:52 AM UTC-8, Jonathan Irving wrote: > > > > > > I agree with much of what you write James - I'm paid to write rails > and > > > node.js code, and I'm finding that node is encouraging me to compose > > > small components and basically sidestep a lot of the issues that rails > > > is designed to address. > > > > > > > Can you give a concrete example? > > Tricky, because my work doesn't belong to me. > > I have a component which collects weather forecasts from a public API > for all of the US. This is isolated from other parts of the app. It > acquires the data in one form, transcodes and strips it down, and puts > it into a mongodb. > > Another component runs async map reduce ops on the data, creates > aggregated and otherwise reduced data. > > Finally, there is a service endpoint which serves the product to another > component, which (irrelevantly) is a rails app. > > Managing the data model for these components is trivial, because they > only touch one kind of data, and they are each very small. What the > rails app sees is a service endpoint with a well defined API. I use no > ODM or ORM, just mongodb queries. >
Doesn't this reflect more on your problem domain than on your choice of tools? The first two components are roughly ETL, and the last is data API? How would this have been different in rails? I've done this in django, and it's the same as you describe here. But more to the point, the pieces you've mentioned can't be composed to build a web app with a UI, and you can't decompose a web app with a UI into just the service layer bits. You also need the UI bits: the forms layer, the validation layer, the admin, etc., etc. To be maintainable, those layers should be common for different components in the application: it does not scale to require devs to learn multiple template languages, multiple migration tools, multiple admin interfaces, etc. -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
