On May 21, 02014, at 7:23, Dan Cancro <[email protected]> wrote: > Hi group, > > I am a new developer researching different ways to make my application and > hoped you might be able to help me out. I like AngularJS for the front and > I'm deciding how to do the back-end. > > My app will be a single-page app on the front and a JSON API on the back. It > will do some heavy computation on the server using a library written in C++. > The data should be pretty isomorphic and have a few joins so I think SQL > would be better than NoSQL, but I don't really understand NoSQL. > > Specifically what I'd like to know is whether a Node.JS framework like > Express provides the following benefits I have read here are provided by Ruby > on Rails. And whether it provides other benefits that I don't know about but > would be useful to me.
I think a lot of this needs to be taken with a grain of salt. Many I don’t know off the top of my head, but large portions of what you want are available. (And generally as modules, not core functions in Express) > > 1) Object-relational mapping No, but that’s orthogonal. There’s packages to do that, depending on your database and how you want to map to relations. > 2) Serve status codes only as responses Sure. Express is a thin layer over HTTP; anything spec-legal should work, and many things that aren’t. > 3) Accept nested, XML, YAML & JSON parameters No, no, yes. But adding middleware to do XML or YAML isn’t going to be very hard at all. > 4) Reload server-side code in development mode Restart the whole server is the simplest way to do it. Usually you can make things start fast. > 5) Protection against IP Spoofing What do you mean? That’s generally a network layer concern, not application layer. > 6) Generate request IDs > Makes a unique request id available, sending the id to the client via > the X-Request-Id header. > The unique request id can be used to trace a request end-to-end and > would typically end up being part of log files from multiple pieces of the > stack. Should be easy to add. > 7) Exception redirection > Rescue exceptions and re-dispatch them to an exception handling > application. I’m not sure what this would mean — capture and then HTTP post to another service? Sure could be done. Not built in, but plumbing like this is easy. > 8) Cache responses > Caches responses with public Cache-Control headers using HTTP caching > semantics. Not in Express by default, but trivial to add. > 9) Test for stale session Defined how? > 10) Automatically set an ETag on all string responses > This means that if the same response is returned from a controller for > the same URL, the server will return a 304 Not Modified, > even if no additional caching steps are taken. This is primarily a > client-side optimization; it reduces bandwidth costs but not server > processing time. Easy to add as middleware; might exist already. > 11) Add a mutex around requests > If your application is not marked as threadsafe, this middleware will > add a mutex around your requests No javascript-visible threading; not an issue. What are you trying to accomplish? > 12) Add timer header to requests > The server adds a header to the request saying how long it took Easy to add via middleware; might already exist. > 13) Allow routing POSTs to other verbs Easy enough to add. Bet it already exists. > 14) Support for signed and encrypted cookies I think it’s been done. Search npmjs! > 15) Best Standards > Tells Internet Explorer to use the most standards-compliant available > renderer. In production mode, if ChromeFrame is available, use ChromeFrame. Not really a concern of the HTTP layer; easy to plumb in though. > 16) Server-side, variable-verbosity logging Sure. Lots of logging libraries available. > 17) Protection against timing attacks Protecting what against timing attacks from whom? > 18) Configurable response caching I’m sure it exists. > 19) Serve URLs based on the route definitions Yes. > 20) Serve headers only Sure. > 21) Basic, Digest and Token Authentication via Passport or others. > 22) Instrumentation > triggers registered handlers for a variety of events, such as action > processing, sending a file or data, redirection, and database queries. The > payload of > each event comes with relevant information (for the action processing > event, the payload includes the controller, action, params, request format, > request > method and the request's full path). Consider looking at restify or hapi or other more API-oriented server frameworks. > 23) Generators for server-side test and MVC parts I bet some people have written them; Not in scope for Express. It’s generally low-boilerplate anyway. > 24) Database change management system Not in scope for express; I’ve not seen anything particularly wonderful in Node, but it’s what (shameless plug!) Modyllic was written for in PHP (usable from any platform — it’s just a tool set), and it may get ported to node.js soon. > I'm also wondering about debugging and whether one back end has better > debugging features than another. restify really has some wins there; lots of options though. Most HTTP frameworks in Node are small, so they’re easy to extend or understand from the ground up. Most involve other components to do more esoteric features. Design tends to be much more modular in node land. Aria
signature.asc
Description: Message signed with OpenPGP using GPGMail
