> 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> 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> 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> 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> 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> 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>wrote: >>>>> >>>>>> On Sun, Dec 16, 2012 at 1:38 PM, Gregg Caines <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 >>>>>> 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 >>>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> -- >>>> 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 >>>> >>> >>> -- >>> 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 >>> >> >> -- >> 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 >> > > -- > 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 > -- 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
