Hi Josh Do you know of a tutorial or sample project that shows you how to do that and what to watch out for?
Julio > On Jan 24, 2014, at 11:14 PM, Joshua Ballanco <jball...@gmail.com> wrote: > > I just wanted to point out that if you’re looking to write small background > processes that are more shell-script-y than server-y, you might consider CLJS > + Node.js. That way you can still leverage Clojure without the need to spin > up an entire JVM just for a quick cron task. > > Cheers, > > Josh > > >> On Saturday, January 25, 2014 at 7:40, Jarrod Swart wrote: >> >> I appreciate your outlook, and yes I have definitely discussed the pros of >> Clojure. They are apprehensive in the event they have to outsource >> development work, and I don't blame them. I'm just going to be a lot happier >> and more productive in Clojure. >> >> Thanks again! >> >> >> >>> On Saturday, January 25, 2014 12:25:51 AM UTC-5, Mikera wrote: >>> Be careful about "weaselling in" Clojure - If I was your client and you did >>> that without consulting me, I'd be pretty annoyed (possibly to the extent >>> of not working with you again). Better to be upfront about the good reasons >>> for using Clojure (concurrency support, awesome libraries, productivity >>> etc.) >>> >>> On the server architecture side: I think it's preferable to package things >>> together into a big JVM instance. Reasons: >>> - It's relatively easy to make some lightweight compojure routes to bundle >>> different APIs / micro-apps together in one app server >>> - It will make deployment much simpler: you can often get away with >>> something as simple as: java -jar myserver.jar >>> - You'll accumulate less duplication / technical debt if you keep >>> everything in sync (library versions, shared utility code etc.) >>> - A single large JVM instance will have a lot less overhead compared to >>> multiple small JVMs >>> - JVM applications are better suited in general to long-running instances >>> rather than small scripts >>> >>> I'd consider breaking this into multiple instances only if there was a good >>> reason, e.g. >>> - Need for process isolation for security / robustness reasons >>> - Need to have different lifecycles for different application servers. >>> >>> >>> Basically you can think of it this way: >>> - cron jobs => process coordination within the server (perhaps core.async, >>> or other scheduling tools) >>> - python scripts / micro-apps => separate Compojure routes / APIs within >>> the server >>> - hacking at the command line => hacking with the REPL >>> >>> >>>> On Saturday, 25 January 2014 12:58:03 UTC+8, Jarrod Swart wrote: >>>> I have a general question about application architecture as it relates to >>>> deploying to the server. >>>> >>>> Most of my previous development work involved python/php/ruby so we >>>> typically had: >>>> >>>> 1. One massive framework / application complection nightmare >>>> 2. Background scripts run by crons >>>> >>>> At present I am working on an application for a client, and I am trying to >>>> weasel in Clojure where I can. I will likely have to make the Clojure >>>> aspects a black box. >>>> >>>> If I were doing this in another language I would simply write the smaller >>>> pieces of functionality as python scripts, plop them on the server and >>>> then set the crons. >>>> >>>> How do I do this with Clojure? If I package each micro-app as an uberjar >>>> that is a lot of JVM, likely eating at the resources of the poor (see: >>>> crappy) VPSs this project will likely run on. >>>> >>>> Thoughts? >>>> >>>> How do you structure web Clojure apps beyond: put the whole thing in a >>>> servlet\uberjar? >> >> -- >> -- >> 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 >> (mailto: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 >> (mailto: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 >> (mailto:clojure+unsubscr...@googlegroups.com). >> For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > -- > 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. -- -- 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.
