This is what I'm doing right now:
Implemented different router modules for different routes
Each router has it's own sets of MongooseModels.
Handler the request (req,res) and interact with the MongooseModel via statics and methods
This is what I want to know:
Almost every example is see where Mongoose,Express are involved, they seem to follow the MVC pattern, which places "Controllers" in between. Now, I have statics and methods defined in each MongooseModel and are capable of handling only the (req.body) part of my original (req) (Because, that's what they only need, right?). Extract the result, and the rest is done by the router.
So, do I really need to place Controllers in between as my MongooseModel is already doing the same job?
Thanks.
Related
I have question about node.js routes. Which routing version is correct?
First version it's a standard version in express.js:
router.get('/packages/:name', (req, res) => {
//my example code
);
Second version with TypeScript. This version is from typeorm init command.
export const Routes = [{
method: "post",
route: "/user",
controller: CustomerController,
action: "createUser"
}];
Which version is better and why? About the second version, how i can add custom middleware? What is difference between first and second version?
Both the approaches are same. When you have a lot of routes for a single point like root/apiv1/[here all the routes] then the second
one is preferable, if you have many dynamic routes, so its better to
go with the first approach.
Talking about the language, you can achieve both kind of routing in
plane JS and also in JS. But due to typecasting and validations,
preferred language is typescript and way of routing depends on the situation.
Talking about the middleware, for the first approach we will pass the
middleware just before the controller function, and for the second
approach, we are bascially creating structures for our routes and we need to
pass these routes to some route() end point, there we will
define the middleware just like we are doing in the first approach.
I have a small-ish project I'm working on and I want to be able to have routes like this work at the same time.
indexRouter.get('/section/:path*', sectionController.pathLogic);
indexRouter.get('/section/about', staticController.about);
Currently, the * in /section/:path* catches everything and /section/about is ignored.
Is there a way to handle both of these routes at the same time?
The order that you define the routes matters, so always put general routes last when you define them. The router traverses down through the tree of routes and if it finds the possible route it stops there (unless it's middleware and calls next()). So in your case, the route with '*' is more general, so the router stops there.
I would like to return localized Strings for multilanguage business objects in our RestFul API based on node.js, restify and mongoose. I have the requirement to store the translated resources on our translation resource server, but also need to support dynamic creation of those business objects.
I found a solution to easily plugin the i18n process in the POST/PUT calls using a single pre-'save' mongoose middleware on all Schema, when creating or updating my multi-languate business objects - this works because I am able to pass the request context to the obj.save(req, callback) call.
But, I am struggling to plug in the i18n on simple GETs. I thought of and tried different ways where I can plugin the i18n before returning the response, but don't really find a good way. Options I thought of:
translate in a mongoose middleware pre /post ('init'):
Problem: I don't have access to the request context, and therefore
don't know the locale to return, so I cannot translate there.
translate in the toObject() / toJSON {transform: }:
Same issue - i don't have the request context in these hooks.
translate in the handler/controller methods for each ressource.
Problem: Duplication, I have to do it everywhere, I would really prefer a solution I can define on the model/Schema layer
translate in a restify / express middleware towards the end:
Problem: I don't have access to the mongoose schema metainformation anymore, so I don't know which attriutes to translate.
Edit: just found this additional way:
- translate in a custom restify responseFormatter:
This seems to work nicely, in the reponseformatter I have access to everything I need. It kind of seems a little weird from an architechtural point of view, but if nobody has a better idea, I will add this as an answer.
Maybe (hopefully) I am missing something obvious...
thanks for any hints
Working with Express js to write a simple NodeJS webservice. I'm historically a python guy.
In frameworks like Django or Flask, its common to see Python decorators used to implement logic from plugins only on specific endpoints. An example of this pattern can be seen here.
http://pythonhosted.org/Flask-Classy/#using-multiple-routes-for-a-single-view
I'm working on an Express middleware and have everything working well with the app.use 3-parity function, but this is only relevant for logic executes for every request. I'd like to allow the end user of the plugin to run parcels of my logic (already in separate functions) only on specific endpoints similar to the pattern outlined in the source above.
Some of the configuration to these wrappers would be passed at app start.
What would be the best approach to this? Should I emulate this pattern with functions that take the actual route handler as an argument and return it at end? Something like this?
function pluginWrapper(endptFunc){
//plugin logic here
return endptFunc;
}
app.get('/endpt', pluginWrapper(function(req,res,next){
//endpt logic here
res.end()
}));
Here are the express idiomatic strategies:
Things relavent for the majority of requests across the entire site become normal connect middleware: app.use(express.cookieParser())
Things relavent for just a particular route can go just on that route: app.post('/users', express.bodyParser(), createUser). This is the pattern I think that most closely matches your above scenario
Groups of related middleware can be passed as lists: app.get('/books', [paginate, queryLimit, memoize], getBooks). And of course that list could be a variable or module and thus shared in a DRY fashion.
Common functionality triggered by patterns in the path itself can use app.param: app.get('/:username/hobbies', getHobbies)
Existing regular functions can be wrapped into middleware to adapt them to a middleware API.
You can just call functions as normal. Not every method of code reuse has to be shoehorned into one of express's convenient patterns.
To address your question more directly, I don't think you should try to port the python decorator pattern 1-to-1 to javascript. Middleware accomplishes essentially the same thing. If you post concrete examples using decorators, we can suggest an idiomatic way to implement them in express.
I am pretty new to node and express.js and I'm new to the concept of REST applications as well. I want to code a typical CRUD app, some sort of diary. Hence, I have a collection of entries, can view a single entry and can add, edit and delete an entry.
I'm not quite getting yet, how URi's have to be set up to represent a REST conform API. I would create something like this in my app.js:
// GET REQUEST ROUTING
app.get('/', diary_router.home);
app.get('/entries/', diary_router.listEntries);
app.get('/entries/:id', diary_router.getSingleEntry);
// POST REQUEST ROUTING
app.post('/entries/', diary_router.addEntry);
// PUT REQUEST ROUTING
app.put('/entries/', diary_router.updateEntry);
// DELETE REQUEST ROUTING
app.delete('/entries/', diary_router.deleteEntry);
Could that be called a REST conform interface? Should I rather add the respective action in the routes, such as this and does the item-ID need to be shown in the URL for PUT and DELETE actions, too?:
// GET REQUEST ROUTING
app.get('/', diary_router.home);
app.get('/entries/', diary_router.listEntries);
app.get('/entries/show/:id', diary_router.getSingleEntry);
// POST REQUEST ROUTING
app.post('/entries/add/', diary_router.addEntry);
// PUT REQUEST ROUTING
app.put('/entries/update/:id', diary_router.updateEntry);
// DELETE REQUEST ROUTING
app.delete('/entries/delete/:id', diary_router.deleteEntry);
What would be best practice here? Any help is much appreciated.
B.
In the loose definition of REST that we seem to have converged on in web-land, the first option seems to fit best.
Edit: and yes, you should specify the ID in the PUT and DELETE routes.
HTTP is a really cool protocol for applying verbs (request methods) to nouns (URLs). In that spirit, it's probably best to use the request method to differentiate what you want to do to the resource that you're requesting.
Note: you can use the methodOverride middleware in express if you're worried about browsers not being able to use arbitrary HTTP methods.
The way the methodOverride middleware works is that you use an <input type="hidden" name="_method" value="PUT"> or similar to specify the method, despite it just being a regular POST request, and the methodOverride middleware will set the method property on the request that you get in your express application. This way, you can signal the intended request method without the client actually having to support that method.