Hi all,
I'm not sure exactly how to phrase my questions, so let me give a bit of
background.
I have a fairly large (and growing) web middleware application that uses
serve/servlet and currently exposes about 90 function URLs, all of the
form "/api/<category>/<function>". The application grew precipitously
and right now there is a lot of duplication in the code - there are many
instances of groups of functions within a "category" that can be
implemented via a common parameter driven function. I was hoping to
refactor to use symbol-arg dispatch here practical.
I know the code can be refactored that way. The problem is the
"practical" part.
There are a small number of heavily used URL functions which I would
like to separate out into a "place" which can be replicated to take
advantage of multiple cores. I have some good reasons [not relevant
here] for not wanting to use separate processes.
Within a single servlet instance I know that dispatch rules are
evaluated in order: e.g., in
:
[ ("api" "foo" "static") #:method "get" do-static ]
[ ("api" "foo" (symbol-arg) #:method "get" do-dynamic ]
:
there is no problem handling "/api/foo/static" separately from other foo
related URLs
However, continuing with this example, if do-static were moved into a
separate place _listening on the same port_, then the symbol-arg version
might erroneously capture and fail a request for the "static" version.
Making the places listen on separate ports is logistically complicated.
My application hides behind Apache, which would need reconfiguration for
every "special" ProxyPass URL whenever the application changed how it
dispatched. Although possible, mucking with Apache is inconvenient and
yet-another-thing to remember to do. It would be better if everything
could be handled entirely within the Racket application.
I thought of keeping all the dispatch in one place, handing off specific
functions to "worker" places. But that too is problematic: the
application is, in part, a specialized search engine ... the functions I
want to separate can, and do, produce large amounts of data that would
be impractical to relay through a common dispatcher place.
I thought of passing the TCP port to the worker place so it could
respond directly. I know the port is accessible inside response/output,
but in that context it seems like it might be difficult to use a
place(d) function to generate the response data. [Maybe not, I haven't
tried it, but I'm concerned about trapping / handling / logging errors.]
It seems to make the most sense to have places dispatch their own set of
requests. However, if I want them to use the same listen port, it
appears that I have to fully enumerate dispatch rule URLs - negating the
possibility of using symbol-arg dispatch to handle commonalities.
Obviously I can dispatch to stubs that redirect to a common function
where possible, but it seems like there should be a less convoluted
solution.
Am I missing something (obvious or not) ? Other, better ideas?
In any event, I thank everyone for "listening". Just venting sometimes
is helpful. :-)
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
