Hey Gregg
FWIW. I like it so far and have started to use it.
I'm mainly experimenting with it at this point, but your framework is a good
fit for what i was looking for.
Thank you.
On Tuesday, 18 December 2012 at 2:06 AM, Gregg Caines wrote:
> > req.on("end", handler) is an event that only happens once and and will only
> > have a single handler in most cases. Just make request, json and body
> > events and make your $ thing an event emitter.
>
>
> I think you've sold me on that. Good points.
>
> > CRUDCollection (its annoying to rename your concepts a day after you
> > publish your ideas on the mailing list) could be something returns a (req,
> > res) function I can pass to any router I want. For example
>
> Sorry. It was actually renamed before I published to the list and I missed
> updating the one spot in the docs that you found. You helped me find a
> documentation bug if it makes you feel any better. :)
>
> > What's im trying to suggest is don't write a JSON framework. Write modules
> > that make writing a JSON API server easier. Then later build whatever
> > opinionated framework you want on top of it.
>
> Alright so there are a couple of problems that I ran into with this approach
> mainly revolving around modularity. Percolator lets you create node modules
> out of the objects that handle the requests for methods of a single
> 'resource'. These modules need more than req and res though if they're going
> to share functionality server-wide. Functionality like error handling, server
> configuration information, inevitable global variables, etc. There are a
> number of aspects that can't just be require()ed in and must be passed at
> runtime. I'd considered a third parameter for that stuff, or monkey-patching
> req and res like express does, but neither seemed very pure from a node
> perspective, so I went with what would be easiest on the app developer, and
> would ultimately make creating a consistent http api easiest.
>
> One good example in CRUDCollection is the triple-duty that fetch() provides.
> That method is called for GET, PUT, and DELETE to determine a 404 scenario
> automatically before the handlers for GET, PUT and DELETE are even called.
> The system-wide error handler is called, with the current request url to put
> out a nice 404 message in the case that the thing could not be retrieved. If
> it could be retrieved, you don't have to make that database call again in GET
> to send it to the user, it's simply available as $.fetched .
>
> These might seem like small things, but these small things are basically
> death-by-1000-cuts when trying to write a real API. See the difference in
> length between the express version and the Percolator version for example (
> http://percolatorjs.com/examples.html ). There's no one place where the
> express version is obviously wordy, and yet it ends up being twice as long.
> What's additionally not shown is that the linksCollection in the percolator
> example could have been require()ed in from a separate file because it
> doesn't rely on closures to share state like the express version does.
>
> I'm interested to hear if you have a better a solution for those problems
> though. Thanks for the feedback again.
>
> G
>
>
>
>
>
>
>
>
>
> On Mon, Dec 17, 2012 at 1:58 AM, Jake Verbaten <rayn...@gmail.com
> (mailto:rayn...@gmail.com)> wrote:
> > > I used the word 'on' in onRequest(), onJson() and onBody(), but those are
> > > not really for streams or even general events and should only ever have 1
> > > handler/listene
> >
> >
> > req.on("end", handler) is an event that only happens once and and will only
> > have a single handler in most cases. Just make request, json and body
> > events and make your $ thing an event emitter.
> >
> > > assume you're basically saying this could've been implemented on top of
> > > express.
> >
> > Hell no. You can implement it on top of http.
> >
> > CRUDCollection (its annoying to rename your concepts a day after you
> > publish your ideas on the mailing list) could be something returns a (req,
> > res) function I can pass to any router I want. For example
> >
> > var module = CRUDCollection({
> > ...
> > })
> >
> > arbitaryRouter.addRoute("/myCollection", module.handler)
> > arbitaryRouter.addRoute("/myCollection/:memberid", module.wildcard)
> >
> > > I didn't care to have a synchronous middleware system
> >
> > Agreed middleware systems are poor.
> >
> > What's im trying to suggest is don't write a JSON framework. Write modules
> > that make writing a JSON API server easier. Then later build whatever
> > opinionated framework you want on top of it.
> >
> > I've listed a few of those modules (
> > https://github.com/Raynos/routil#routil ),
> > [npm-www](https://github.com/isaacs/npm-www) demonstrates a bunch more of
> > those modules.
> >
> >
> > On Sun, Dec 16, 2012 at 4:21 PM, Gregg Caines <gr...@caines.ca
> > (mailto:gr...@caines.ca)> wrote:
> > > Ohh good questions...
> > >
> > > > There doesn't seem to be any support for streams which sucks.
> > >
> > > Check out http://percolatorjs.com/documentation.html#context-req and
> > > http://percolatorjs.com/documentation.html#context-res . Those are the
> > > unaltered request and response objects, so you can still stream as well
> > > you ever could from the node standard library. There's no synchronous
> > > middleware system like connect here either, so you basically get the
> > > stream as soon as node does too.
> > >
> > > > Using `onX(cb)` instead of `.on("x", cb)` is going against the grain of
> > > > node for no reason.
> > >
> > > I used the word 'on' in onRequest(), onJson() and onBody(), but those are
> > > not really for streams or even general events and should only ever have 1
> > > handler/listener, so I didn't feel the need to try to emulate the streams
> > > or events API. Let me know if you think they're more 'eventy' than I do
> > > though. I could certainly name them setRequestPreprocessor(), withJson(),
> > > and withBody() too if that leads to less confusion with event/stream
> > > APIs. I'll have to throw this around in my brain a bit.
> > >
> > > > And other then the Hyper+JSON and JSONmodule thing there doesn't seem
> > > > to be something here that isn't covered by other libraries.
> > >
> > > I'm going to go out on a limb and assume you're basically saying this
> > > could've been implemented on top of express. That's not the case though
> > > once you get into the details:
> > >
> > > * Percolator comes with completely different routing that lets you build
> > > re-usable components (like that JSONModule). Building that on top of
> > > express (where two methods of the same resource know nothing of one
> > > another) would have been gnarly and not really got me much more than
> > > node's standard http server does. The standard lib does a heck of a lot.
> > > * I didn't care to have a synchronous middleware system like connect,
> > > because I've yet to find a case for a middleware system like that that
> > > can't be handled by a 1-liner lazily, and on-demand ($.onJson() is a good
> > > example of that -- 80% of my requests never need a bodyParser, and the
> > > ones that do get it with 1 line).
> > > * I didn't want to have any dynamic html generating functionality at all
> > > (though it's easily added to an app). If your app is more website-y and
> > > not a single-page-app-y, then express is simply the better choice. If you
> > > have a single page app with static assets backed by an API, then you're
> > > in Percolator's sweet spot. I generally think PJAX should die in a fire
> > > though, so I don't care to contribute to it. I said this was an
> > > opinionated framework, right? :)
> > >
> > > There are a whole lot of things outside of json apis that express can do
> > > that Percolator will never do either, so I'd never try to compare this to
> > > express in general (express is better at basically everything else, even
> > > in my biased opinion). Percolator was more inspired by webmachine (
> > > https://github.com/basho/webmachine/wiki ) and its use-cases than sinatra
> > > though, so it naturally doesn't use express.
> > >
> > > Thanks for the input!
> > >
> > >
> > > On Sun, Dec 16, 2012 at 3:04 PM, Jake Verbaten <rayn...@gmail.com
> > > (mailto:rayn...@gmail.com)> wrote:
> > > > Using `onX(cb)` instead of `.on("x", cb)` is going against the grain of
> > > > node for no reason.
> > > >
> > > > I recommend you change that api.
> > > >
> > > > There doesn't seem to be any support for streams which sucks.
> > > >
> > > > And other then the Hyper+JSON and JSONmodule thing there doesn't seem
> > > > to be something here that isn't covered by other libraries.
> > > >
> > > > Which means I recommend you take those two concepts and make them
> > > > seperate open source libraries
> > > >
> > > >
> > > > On Sun, Dec 16, 2012 at 1:28 PM, Gregg Caines <gr...@caines.ca
> > > > (mailto:gr...@caines.ca)> wrote:
> > > > > Totally agree, but I'm not even done the server-side yet. :) I'm not
> > > > > even entirely sure what the client library should do yet (beyond the
> > > > > standard http stuff like request or super-agent do), and the only
> > > > > consumers of the API I've written with it are in ruby and erlang, so
> > > > > I'm even a little language agnostic for client libs.
> > > > >
> > > > >
> > > > > On Sun, Dec 16, 2012 at 12:00 PM, Jonathan Chayce Dickinson
> > > > > <jonathand...@gmail.com (mailto:jonathand...@gmail.com)> wrote:
> > > > > > Good work! Vannevar Bush would be proud of you :).
> > > > > >
> > > > > > A client library to consume this would be nice...
> > > > > >
> > > > > > Jonathan
> > > > > >
> > > > > > On Sun, Dec 16, 2012 at 9:24 PM, Scott Elcomb <pse...@gmail.com
> > > > > > (mailto:pse...@gmail.com)> wrote:
> > > > > > > On Sun, Dec 16, 2012 at 1:38 PM, Gregg Caines <cai...@gmail.com
> > > > > > > (mailto:cai...@gmail.com)> wrote:
> > > > > > > > Hey all... I've been working on a new framework for restful
> > > > > > > > json apis for a
> > > > > > > > while, and was wondering if anyone might be interested in
> > > > > > > > taking a look,
> > > > > > > > giving feedback, etc.
> > > > > > > >
> > > > > > > > http://percolatorjs.com
> > > > > > >
> > > > > > > Is it fair to assume that percolatorjs is an implementation of
> > > > > > > your
> > > > > > > application/vnd.hyper+JSON draft at
> > > > > > > <http://caines.ca/blog/programming/hyperjson-a-first-draft/> ?
> > > > > > >
> > > > > > > --
> > > > > > > Scott Elcomb
> > > > > > > @psema4 on Twitter / Identi.ca / Github & more
> > > > > > >
> > > > > > > Atomic OS: Self Contained Microsystems
> > > > > > > http://code.google.com/p/atomos/
> > > > > > >
> > > > > > > Member of the Pirate Party of Canada
> > > > > > > http://www.pirateparty.ca/
> > > > > > >
> > > > > > > --
> > > > > > > Job Board: http://jobs.nodejs.org/
> > > > > > > Posting guidelines:
> > > > > > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > > > > > > You received this message because you are subscribed to the Google
> > > > > > > Groups "nodejs" group.
> > > > > > > To post to this group, send email to nodejs@googlegroups.com
> > > > > > > (mailto:nodejs@googlegroups.com)
> > > > > > > To unsubscribe from this group, send email to
> > > > > > > nodejs+unsubscr...@googlegroups.com
> > > > > > > (mailto:nodejs%2bunsubscr...@googlegroups.com)
> > > > > > > For more options, visit this group at
> > > > > > > http://groups.google.com/group/nodejs?hl=en?hl=en
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Job Board: http://jobs.nodejs.org/
> > > > > > Posting guidelines:
> > > > > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > > > > > You received this message because you are subscribed to the Google
> > > > > > Groups "nodejs" group.
> > > > > > To post to this group, send email to nodejs@googlegroups.com
> > > > > > (mailto:nodejs@googlegroups.com)
> > > > > > To unsubscribe from this group, send email to
> > > > > > nodejs+unsubscr...@googlegroups.com
> > > > > > (mailto:nodejs%2bunsubscr...@googlegroups.com)
> > > > > > For more options, visit this group at
> > > > > > http://groups.google.com/group/nodejs?hl=en?hl=en
> > > > >
> > > > >
> > > > > --
> > > > > Job Board: http://jobs.nodejs.org/
> > > > > Posting guidelines:
> > > > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > > > > You received this message because you are subscribed to the Google
> > > > > Groups "nodejs" group.
> > > > > To post to this group, send email to nodejs@googlegroups.com
> > > > > (mailto:nodejs@googlegroups.com)
> > > > > To unsubscribe from this group, send email to
> > > > > nodejs+unsubscr...@googlegroups.com
> > > > > (mailto:nodejs%2bunsubscr...@googlegroups.com)
> > > > > For more options, visit this group at
> > > > > http://groups.google.com/group/nodejs?hl=en?hl=en
> > > >
> > > >
> > > > --
> > > > Job Board: http://jobs.nodejs.org/
> > > > Posting guidelines:
> > > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > > > You received this message because you are subscribed to the Google
> > > > Groups "nodejs" group.
> > > > To post to this group, send email to nodejs@googlegroups.com
> > > > (mailto:nodejs@googlegroups.com)
> > > > To unsubscribe from this group, send email to
> > > > nodejs+unsubscr...@googlegroups.com
> > > > (mailto:nodejs%2bunsubscr...@googlegroups.com)
> > > > For more options, visit this group at
> > > > http://groups.google.com/group/nodejs?hl=en?hl=en
> > >
> > >
> > > --
> > > Job Board: http://jobs.nodejs.org/
> > > Posting guidelines:
> > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > > You received this message because you are subscribed to the Google
> > > Groups "nodejs" group.
> > > To post to this group, send email to nodejs@googlegroups.com
> > > (mailto:nodejs@googlegroups.com)
> > > To unsubscribe from this group, send email to
> > > nodejs+unsubscr...@googlegroups.com
> > > (mailto:nodejs%2bunsubscr...@googlegroups.com)
> > > For more options, visit this group at
> > > http://groups.google.com/group/nodejs?hl=en?hl=en
> >
> >
> > --
> > Job Board: http://jobs.nodejs.org/
> > Posting guidelines:
> > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > To post to this group, send email to nodejs@googlegroups.com
> > (mailto:nodejs@googlegroups.com)
> > To unsubscribe from this group, send email to
> > nodejs+unsubscr...@googlegroups.com
> > (mailto:nodejs%2bunsubscr...@googlegroups.com)
> > For more options, visit this group at
> > http://groups.google.com/group/nodejs?hl=en?hl=en
>
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> (mailto:nodejs@googlegroups.com)
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> (mailto:nodejs+unsubscr...@googlegroups.com)
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
