Re: [nodejs] new framework for json apis
I mostly agree, but I personally think it's worse than you make it out to
be. Take a look at the Percolator and express examples at
http://percolatorjs.com/examples.html and you'll see that most of the
reason that the express version is ~2x longer is due to error handling. I
find setting up error-handlers to be boring as hell and frankly don't want
to do it anymore. Also see the absolutely brilliant webmachine state
machine diagram at
https://raw.github.com/wiki/basho/webmachine/images/http-headers-status-v3.pngto
see all the kinds of errors that can occur, many before you even
route.
And when a good REST API responds with a 404, for example, it should do so
in exactly the same way every time regardless of whether the 404 is found
in the router (no route exists) or in the resource (the requested item
doesn't exist in the database).
Real-world apps need to share a lot more across response handlers than just
error-handling though. In just my current app I need to share these common
services amoung the different response handlers: statsd, the database, a
logger, and a message queue.
And any time you want to share any centralized resource, it either needs to
be:
1. explicitly passed (breaking the function(req, res) signature)
OR
2. monkey-patched on either of the req or res objects
OR
3. you're stuck with closures implicitly pulling in external state.
I threw out #3 immediately because relying on closures and external state
keeps me from splitting up my response handlers into separate
modules/files. I also found #2 to be kind of unsanitary, and only
superficially more consistent with the node http server than #1. Let's
face it, if req and res aren't exactly what node gives back, then you've
lost backward compatibility anyway. It's not enough for them to be named
the same and contain mostly the same stuff if the code inside makes use of
any of the differences (and the entire point is to make use of the
differences).
Let me know if you have better ideas for solving these problems though...
G
On Mon, Dec 17, 2012 at 5:53 PM, Jake Verbaten rayn...@gmail.com wrote:
The problem of how do I write a generic request handler but still let the
user decide how to handle errors is frustratingly hard.
The best solution I have come up with is.
router.addRoute(/thing, require(route-handler)({ error:
myErrorFramework }))
which is annoying at best. you hard couple the signature of the error
callback to a particular neutral signature that your error framework
handles.
But really it's not that bad. You configure your application wide error
handling system, then configure all your routes in routes.js and pass in
the error handler to each route handler.
When building things like these I've only found error handling to be that
annoying thing that you need everywhere and only be configured once.
On Mon, Dec 17, 2012 at 7:36 AM, Gregg Caines gr...@caines.ca 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
Re: [nodejs] new framework for json apis
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.
Re: [nodejs] new framework for json apis
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(),
Re: [nodejs] new framework for json apis
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
Re: [nodejs] new framework for json apis
Very cool, Shaun... Feel free to give me a shout anytime if you have questions, or find bugs. G On Mon, Dec 17, 2012 at 3:55 PM, shaun etherton shaun.ether...@gmail.comwrote: 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. -- 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
Re: [nodejs] new framework for json apis
The problem of how do I write a generic request handler but still let the
user decide how to handle errors is frustratingly hard.
The best solution I have come up with is.
router.addRoute(/thing, require(route-handler)({ error:
myErrorFramework }))
which is annoying at best. you hard couple the signature of the error
callback to a particular neutral signature that your error framework
handles.
But really it's not that bad. You configure your application wide error
handling system, then configure all your routes in routes.js and pass in
the error handler to each route handler.
When building things like these I've only found error handling to be that
annoying thing that you need everywhere and only be configured once.
On Mon, Dec 17, 2012 at 7:36 AM, Gregg Caines gr...@caines.ca 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 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
Re: [nodejs] new framework for json apis
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
Re: [nodejs] new framework for json apis
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
Re: [nodejs] new framework for json apis
Does not seem to use standard REST calls - that is a no start - needs to be as simple as php slim, then would be really nice Sent from my LG Mobile 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
Re: [nodejs] new framework for json apis
Kinda-sorta-almost. That draft makes it look more complicated than it is though. And nothing forces you to follow that format either. You can still make old-school arbitrary json apis like twitter and facebook do, if you really want to. On Sun, Dec 16, 2012 at 11:24 AM, 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
Re: [nodejs] new framework for json apis
I assume you mean the standard HTTP methods? I agree... That would indeed be a no-starter if I'd left those out. :) Check the docs at http://percolatorjs.com/documentation.html#server-route . They show the use of multiple methods on one resource. You can add others as well as you'd no doubt expect. This is different from express/sinatra in that I try to promote keeping every method of a single route together in a single place. This makes for better code organization and re-use, and lets the framework handle some HTTP errors more correctly. I still need to document better and make this stuff more obvious, so thanks for the feedback. G On Sun, Dec 16, 2012 at 12:11 PM, Tiger Nassau Inc john.tigernas...@gmail.com wrote: Does not seem to use standard REST calls - that is a no start - needs to be as simple as php slim, then would be really nice Sent from my LG Mobile 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
Re: [nodejs] new framework for json apis
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
Re: [nodejs] new framework for json apis
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
Re: [nodejs] new framework for json apis
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
