node.js variable scope with routes separation - javascript

my routes are defined in an external folder
./routes
here's the way i define the routes in my server.js file
app.get('/', routes.index);
app.post('/validation', register.valid);
the register.valid module, which is originally written in
./routes/validation.js
is responsible for creating a new user account and register it into a database (MongoDB).
How can i access an object from server.js in validation.js ? First, i thought declaring the object before defining my routes would resolve the case, but actually it doesn't seem to be the solution.

I'm assuming your current code already does work (that is, you receive the posted data), but you need access to another object from validation.js.
If your code works, then you probably have this line in server.js:
var register = require('./routes/validation');
And you need acess to the variable obj in the validation module. You could have a function inside the validation module:
var foo;
exports.configure = function(obj) {
foo = obj;
}
The exports mean the variable configure will be accessible to modules which "require" the validation module. This way you can do, inside the server.js module:
register.configure(obj);
app.post('/validation', register.valid);
The exact configuration of this will depend on what you are actually trying to accomplish. Sometimes, for example, it's good to have a database object stored in a global variable.

Generally in this kind of structure server.js will create the app object and then pass that to individual routes modules via a function. I do it by having each router module export a single function like this:
//routes/validation.js
function setup(app) {
app.get(....blah
app.post(....blah
}
module.exports = setup;
Then I tie that together in server.js like this:
//server.js
var express = require('express');
var app = express();
require('./routes/validation')(app);
See also my express_code_structure sample project for other code organization tips.

Related

How to make variables of one file accessible along the entire application?

I have a Node REST API using Express and JavaScript. I created a Database class that is able to connect, disconnect and execute the queries. My app.js (the entry file) creates an instance database of this and launches the express server. On requests I have the following flow:
requests call the middleware functions and finally the controller
the controller calls some other classes and passes in the data
Lastly these classes call the query files to access the database
The query files themselves need to access the instance of the database class. They can call the query function and pass in their prepared statement. I am not sure how to transport the instance database from my app.js (entry file) all the way to those query files.
I found multiple solutions:
using global variables
add the instance to the request object
add the instance to the response locals
add the instance to the app locals
What is the best way/practice to transport variables from one file to the whole application?
Use service architecture or dependency injection.
Service architecture Way:
Make a directory structure like this:
root (directory)
|
|-->app.js
|-->controllers (directory)
|-->services (directory)
|
|-> DatabaseService.js
|-> XYZService.js
|-> index.js
Now in your index.js file require the service classes and export the instances of those classes, like so:
var Database = require('./DatabaseService')
var XYZ = require('./XYZService')
module.exports = {
database: new Database(),
xyz: new XYZ()
}
Now, require these services wherever you want in your code, like so:
// SomeController.js
var database = require('../services').database
...
// DO WHATEVER YOU WANT WITH 'database' variable
...
Dependency Injection Way:
I'm assuming you are using express routes. Do a dependency injection by wrapping your route-controller inside a lambda function, like so:
api.get('/user/:id', function (req, res) { // <-- wrapping
var database = new Database()
return yourRouteController(req, res, database) // <-- Inject your database instance here
})
PS I personally prefer the Service way as it's more modular and readable.
The only other solution I've seen for something like this is using dependency injection. It's still using the global variable but instead of tossing it down the line from one class to the other, you could call up that particular instance of your db connection at any point while your app is runnning.

Express - Accessing top-level express function through dot-notation

In a simple javascript file, we can use express by adding these two lines of code at the beginning (after installing it through npm):
var foo = require('express');
var app = foo();
Now, according to the express API guide:
The app object conventionally denotes the Express application. Create it by calling the top-level express() function exported by the Express module
Since the app object is calling the top-level express() function, how come am I not able to just simply use:
var app = foo.express();
The first line assigns whatever the module 'express' exports to a variable named express. Different modules will export different things (objects, functions). Express exports a function.
The line:
var app = express()
executes the function. This function generates the express application object. This object has all the methods that you use to handle requests in your standard express apps.
The require function that was passed 'express' returns module.exports, which holds the top level function express(), something similar to:
module.exports = express(){...}
That is why we still need to call it either through:
var foo = require('express');
var app = foo();
or
var app = require('express')();
You cannot use:
var foo = require('express');
var app = foo.express();
because it was not set up that way, you could use it if the express module looked something like this:
module.exports.express = express(){...}
I don't know the reason as to why you would choose one over the other, I only know that the second technique simply exposes your function directly.

Impact and alternatives on requiring some of the same packages in every modules of my node.js application?

Let's say I have an application as following:
server.js (main) is requiring different external node packages, like underscore.js.
var Underscore = require("underscore");
server.js is also requiring some modules defined in my application it-self; For example it could requires a Router module, to handle Express routes.
var Router = require("./sources/router.js");
I have then my router.js file as following :
var Router;
Router = (function() {
function Router(app, oauth) {
app.get('/', function(request, response) {
// ...
});
}
return Router;
})();
module.exports = Router;
Questions:
If I want to use underscore inside my Router module, should I re-require again ? Should I do that for every modules ? What is the impact?
I would end up with something like:
var Router;
Router = (function() {
Router.prototype.underscore = require("underscore");
function Router(app, oauth) {
app.get('/', function(request, response) {
// this.underscore. ...
// using underscore ...
});
}
return Router;
})();
module.exports = Router;
and
var Underscore = require("underscore");
var Router = require("./sources/router.js");
router = new Router();
I could obviously also inject as a parameter it when initializing Router, but this doesn't look to me like a viable option in an application where I may end up using dozens of packages, especially for very general purpose package like this one.
var underscore = require("underscore");
var Router = require("./sources/router.js");
var router = new Router(underscore);
Alternatively I could set the underscore var as a global one, but I don't really like this option.
Is there any other options ?
What is the impact of systematically importing packages in every modules - in term of execution time, memory ?
I would like to understand the behavior of the node engine in such cases.
Yes, you should just require it again. Node caches required modules, so the second time you require something it doesn't actually run that file; it just returns the cached object. So the memory impact is basically 0 (an extra pointer to the same object, more or less) and the execution time is similarly negligible (the cost of a lookup in an object by the module name).
This means that the objects returned by the two requires aren't just identical; they're literally the same object. Any change to one will affect the other. Because of this, you can extend the module in one place and get those extensions everywhere.

What is the best way to pass global config variables to handlebars template?

Ive a nodejs app with express-handlebars and i am wanting to define variable for things like the 'host' address for CSS and Javascript that are currently being imported in a header.hbs file that i call form within the specific layout.
Ive created a config.js file which has a number of variables i want to set and ive imported that into the app.js using:
var config = require('./config.js');
but then im lost as t where to go. for example i was thinkging if i can some how do something like this:
<link href="{{config.csshost}}basev1.css" rel="stylesheet" type="text/css" />
Can anyone provide some pointers, am stumped other than declaring these variable every time i load the template.
You would set the app locals:
var app = express()
app.locals = {
config: config,
templateVar: 'test'
}
Edit:
Your routes will look something like this:
app.get('/', function(req, res) {
res.render('index', {config: config});
})
What this does, is then update the app.locals variable in express to look like this:
app.locals = {
config: config
}
All the app.local variables are then accessible in your templates via:
{{config}}
//which is really
app.locals['config']
So, in your app.js where you configure express you would do this:
var app = express();
app.locals.config = require('./config')
app.get('/', function(req, res) {
return res.render('index')
})
(This should be a comment to sctskw's answer above, but I don't have enough reputation to do that.)
Rather than overwriting app.locals with a new object, it would be better to add new properties to the existing one, like this:
app.locals.config = config;
app.locals.templateVar = 'test';
The reason is that Express uses app.locals internally. Overwriting it would lose some useful variables Express provides. For example, we could use settings.env to detect the current running environment in a view template, which is defined as app.locals.settings.env by Express.

Access generated values from app.js inside a script loaded via require()

I have an Express.js Node web app. Inside my app.js, I generate a string during app initialization:
// app.js
var mongourl = /* based on process.env.VCAP_SERVICES constant */;
Now, I have a script that I load into app.js via require():
// app.js
var db = require('./db');
This script needs to use the mongourl variable defined in my app.js. What would be a good approach to perform this. I have found that I can just set the string as a process.env value, e.g.
// app.js
process.env.mongourl = /* creating the string */;
which then can be accessed in db.js via process.evn.mongourl but I'm not sure if this is a good pattern.
// in db.js you could require an app config.js file
var config = require('config');
// then access via config.db.url
// or you can pass stuff to modules
var db = require('./db')(mongourl);
// or in app.js use app.set()
app.set('mongourl', mongourl);
// then wherever you need it: app.get('mongourl')
I'm not sure if this is a good pattern
It isn't, you just pollute the global object that doesn't belong to you. Consider using a namespace, at least.
A more idiomatic approach would be to create a constructor function for the db connection which takes the string.
It doesn't have to be an actual constructor you could just add
var dburl;
exports.init = function(param) {
dburl = param:
}
Environmental variables aren't meant for that really as they are global and can be seen (and collide with) other modules. Setting it explicitly means it's local and you have much more explicit control of how it's defined if you need it async.

Categories