On Thu, Nov 14, 2013 at 2:53 PM, Brian Craft <craft.br...@gmail.com> wrote:
> On Thursday, November 14, 2013 10:50:48 AM UTC-8, Jonathan Irving wrote: > >> * Brian Craft <craft...@gmail.com> [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, > True say. There is another app that would be a better example, but it is not mine - a node API service, a node web app serving an AngularJS client, and an agent which performs work tasks for the app. The latter can be exec'd by the web app, or from the command line. It is a better example, but I don't know it as well because it isn't my code. I can also imagine composing an app as described by tjholowaychuk here: http://vimeo.com/56166857 - where each component has its own middleware stack based on its specific requirements; I can imagine some being API endpoints, others being bits of template or html/js client code, etc. But I think this is kind of off topic. 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. > I'm hoping to be convinced otherwise - though I agree that you need those different bits, I disagree with the rest of that paragraph. I certainly don't have a problem with multiple languages and multiple sets of tools. I suspect you have different criteria for "maintainable" than I do - for example, you seem to be saying that scaling out development to a group of people who can't handle multiple languages, tools, admin interfaces, is a requirement for you, which it isn't for me. I'm not really that interested in admin interfaces at all for example. So I'll respectfully disagree and look out for some suggestions from people who have made this work. Also, remember that I already do use rails, and am quite attached to its schema management tools - but I want to discover another way, not be convinced its impossible. cheers, J -- -- 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.
