FAQ
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
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Mikera at Jan 25, 2014 at 5:34 am
    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
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jarrod Swart at Jan 25, 2014 at 5:40 am
    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
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joshua Ballanco at Jan 25, 2014 at 7:14 am
    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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jarrod Swart at Jan 25, 2014 at 6:50 pm
    I've thought about this in the past, but the callback style node requires
    is not very appealing to me for scripting. Most python scripts I write are
    very imperative/sequential, does CLJS abstract any of that away?
    On Saturday, January 25, 2014 2:14:05 AM UTC-5, Joshua Ballanco 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 clo...@googlegroups.com<javascript:>(mailto:
    clo...@googlegroups.com <javascript:>)
    Note that posts from new members are moderated - please be patient with
    your first post.
    To unsubscribe from this group, send email to
    clojure+u...@googlegroups.com <javascript:> (mailto:
    clojure+u...@googlegroups.com <javascript:>)
    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+u...@googlegroups.com <javascript:> (mailto:
    clojure+u...@googlegroups.com <javascript:>).

    --
    --
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Julio Barros at Jan 26, 2014 at 3:59 pm
    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 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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Joshua Ballanco at Jan 26, 2014 at 7:53 pm
    I don’t have much practical experience with CLJS+Node myself, but the intro on the ClojureScript wiki has been helpful with the couple experiments I’ve tried: https://github.com/clojure/clojurescript/wiki/Quick-Start . Really, though, it comes down to the fact that ClojureScript compiles down to JS, and you can just hand those over to Node to be run. Sorry I can’t be of more help…

    Cheers,

    Josh

    On Sunday, January 26, 2014 at 17:59, Julio Barros wrote:

    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 (mailto:jballanc@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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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 (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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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 (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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@googlegroups.com (mailto:clojure+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John walker at Jan 26, 2014 at 8:05 pm
    I spent some time yesterday with node webkit and clojurescript. There's not
    really much to it.

    There's a :target :nodejs that you can hand off to leiningen, but I don't
    really know what it's for (and no one else seems to either). Make sure that
    when you inspect the resultant javascript source that you see the google
    closure inlined. This means fiddling with compilation settings. From then
    on, you can follow nodejs tutorials.
    On Sunday, January 26, 2014 10:59:29 AM UTC-5, Julio Barros wrote:

    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 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 clo...@googlegroups.com<javascript:>(mailto:
    clo...@googlegroups.com <javascript:>)
    Note that posts from new members are moderated - please be patient with
    your first post.
    To unsubscribe from this group, send email to
    clojure+u...@googlegroups.com <javascript:> (mailto:
    clojure+u...@googlegroups.com <javascript:>)
    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+u...@googlegroups.com <javascript:> (mailto:
    clojure+u...@googlegroups.com <javascript:>).


    --
    --
    You received this message because you are subscribed to the Google
    Groups "Clojure" group.
    To post to this group, send email to clo...@googlegroups.com<javascript:>
    Note that posts from new members are moderated - please be patient with
    your first post.
    To unsubscribe from this group, send email to
    clojure+u...@googlegroups.com <javascript:>
    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+u...@googlegroups.com <javascript:>.
    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+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Craig at Jan 25, 2014 at 7:23 am
    My current approach accords with Mikera's suggestion, and using a single
    package allows me to easily leverage other components (management, database
    etc). I have an open mind on the future use of isolated scripts (in python
    or whatever), but at the moment I am enjoying the simplicity of developing
    and deploying one artifact.
    On Saturday, January 25, 2014 3:58:03 PM UTC+11, 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
    Note that posts from new members are moderated - please be patient with your first post.
    To unsubscribe from this group, send email to
    clojure+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupclojure @
categoriesclojure
postedJan 25, '14 at 4:58a
activeJan 26, '14 at 8:05p
posts9
users6
websiteclojure.org
irc#clojure

People

Translate

site design / logo © 2022 Grokbase