I'm trying to figure out how best to architect my app. But for starters trying to understand typical practices with respect to where to put things, and how the app should wire up to things like server.js, how server.js should work, and how you keep a persistent connection open for the website, and any backend services or modules.
This is a general question but let me try to be more specific, as specific as I can since I am new to Node.. and for a basis to start on with this question.
Lets say I plan on designing a simple Express App.
I've got this kind of structure for example so far:
Right now in server.js, I am just playing around with trying to connect to a mySQL database. So I've got a connection pool I'm creating, one call to the store to retrieve data, requires at the time for the node-mysql middleware I'm using, etc.
app.js just has very simple code, it's not modular yet, or even production ready but that's just me playing with the code, spiking things out. So in it I have you're typical stuff like setting the view, var app = express();, importing an express route definition from another module in my routes\index.js, stuff like that.
if I'm going to keep a database connection open, or other things open, how is that best organized/done by convention?
If you look at this example code, he's moving the var app = express() definition into service.js: https://github.com/madhums/node-express-mongoose-demo/blob/master/server.js. He keeps an open connection running and started from there, which makes sense, hence "server".
so should app.js do much? what is best practice or scope of what this should be doing. Once I start modularizing things out into their own .js files and node modules, how does the app.js morph through all those refactorings, meaning in the end what's its role and is it very thin in the end where it's just used to wire stuff up?
Then what should www.js which is now required by express 4 have and it's role?
It's kinda hard for me to start with just one aspect so I'm kinda going all over the place here in the above. I just want to know common conventions for putting stuff in app.js vs. server.js and then best way to keep and managed open connections to things...both in the backend and front-end such as http requests coming in, what should be the central point? routes of course but then so is app.js responsible for referencing routes?
I have found a few resources such as this but looking for more so if you know any or have any input, please reply. I'm more interested in the talk around app.js, server.js, connections, www.js, and where things should wire up to each other with these particular specific parts. I realize the rest is up to you on how you wanna name folders, etc.
There is no right way and (arguably) no wrong way. There are which are better than others, but then someone might say that they don't like this way and you should do it the other way and so on, until your project is over the deadline.
I often refer to this blog post about best practices when developing an express app.
You could also try one of yeoman generators. Choose one that suits most/all of your needs.
Bottom line, there is sadly still no answer to best structure of an app, I would recommend you to pick something that works best for you (and your team) and stick with it. Consistency is the most important thing to keep in mind while developing and JavaScript community it clearly lacking it.
Related
I have always wondered how can I do this..
if you go https://community.nodebb.org/topic/14103/strange-thing-on-this-forum
It shows a thread in a forum.
But you can actually access to that same page with https://community.nodebb.org/topic/14103
and then this url changes to the 1st one above.
How can I do this in Node.js?
Node itself is just the language, what you're asking about happens in a framework, like Express.
In Express (and most other frameworks) you can define routes based on either strings, symbols, or a regex. In your above example, the route definition is likely looking for topic/:id and also set to accept anything put after the ID.
Look at the basics of Routing in Express to see how this works.
I'm looking into node.js which really seem like a pretty nice environment. I've worked with a lot of different Technologies and for server, mainly php and Java (jsp), but dabbled in som RoR and Python.
I find node.js really easy to get up and running and it feels quite natural to work with, and I found some good entry level tutorials.
I just am missing some more intermediate resources. For example when creating bigger frameworks or api's how would you structure or architect it. I set up some smaller api's to try it out where it would go something like this:
I've made use of the Express framework to create a http server, listen to a port, set up an express object and bound some requests.
However these have been quite small, and the purpose has been learning, if I think about scaling up the size of the API for production, perhaps wanting to do other stuff like serve web-pages as well. I find it hard to see how the architecture would look.
It's vague as I am still new to node.js but I'm mainly thinking about things like if you typically keep all api in one file or if there are good ways to split it up into modules? And if anyone know any resource talking a bit more about how to design the architecture when working in node.js
Sorry for the vague question and thanks for reading.
In my opinion, Express is the good way to go if you want to build complex or big APIs.
It is among others easily testable (for instance with Mocha or Jasmine) and customizable, especially thanks to its middlewares.
For the directory structure, what I usually use is (at least) the following:
app.js : the main entrypoint. Will create the express application, indicate which controller to use for every route prefix, and assign the middlewares. Example from a previous project
controllers : will contain the controllers, the functions which will handle the requests, in the same style as in standard MVC frameworks (e.g. UserController, ...). Each controller would create an express Router object and export it. Inside the controllers, individual handlers are in charge of individual API requests, such as /api/users/list. It would use some library to access your data (e.g. Mongoose for MongoDB), and would then send the response to the client. Example (UserController.js)
models : will contain the models with all their attributes and methods. In my case, it would be the Mongoose models. Example (Song.js)
middlewares : will contain the various middlewares of the project. A practical example would be a middleware checking for an access token in the incoming request, and returning a 403 HTTP error if not. Example (AuthMiddleware.js)
helpers : various helpers
tests : unit tests of you API
This could be the minimal directory organization. On top of that, you may want to use a templating engine such as EJS to serve webpage. Take a look at « Use EJS to template your node application ».
This is only to give you an overview of what an express directory structure could look like, but there are of course plenty (better?) other possibilities. Hope that gives you a quick and useful insight :)
I am new to Node and web development. I am working on a simple application to get started and want to limit the use of my endpoints to server side calls, i.e. anyone else trying to access them gets a 403.
However, after researching, I found PassportJS with examples of how to protect endpoints, but they all seem to be overkill especially for a small application like mine.
Am I overthinking this, or should I be looking for a more basic solution?
How do you need to consume these end points yourself? I don't know if all you are looking to do is to call one file from the other. You need not expose them as restful end points in that case. Create the methods as module methods (as in node modules). Then just use require syntax to reference that file as a dependency.
You need restful end points for server side only if it needs to be called from another web application.
In looking at the Node.js boilerplate app you get with a Bluemix application, there is a package called IBMSecurity. It seems to imply that by merely putting some routes after it, those routes will require a tokenized call from your mobile app.
//uncomment below code to protect endpoints created afterwards by MAS
var mas = require('ibmsecurity')();
app.use(mas);
Is this accurate? If you read the docs here, http://mbaas-gettingstarted.ng.bluemix.net/node#get-started-with-security, it says it locks down everything, not the routes after it. So it appears to be a bit unclear. If support for both is there, it should be mentioned in the docs as it makes the feature more appealing if you can pick and choose which routes are locked down.
#Raymond Camden, if you are asking that the doc section
http://mbaas-gettingstarted.ng.bluemix.net/node#get-started-with-security
describes method to enable application security using authentication, then it is right. I am reading from you question '... says it locks down everything, not the routes after it. So it appears to be a bit unclear. ...'. I do not read anything like that in the doc. Can you please clarify what section/paragraph you are reading that implies it locks down everything?
I am working on a small hobby project, where I would really like some input and advice.
This is my first "real" node project, and I hope it will teach me a lot about node.js development. I am a .net developer by day, and have been for about 15 years professionally. I have had periods of doing Java as well. I have created small node.js projects to be used as micro services.
But this project can no longer be classified as a micro service ;-)
The purpose of the project is to sample some sensor data, and do some reporting. An idea I got from playing around with a PLC at university. I do that by sampling from a PLC, and emitting the data using ZeroMQ. My node.js server then listens for this sensor data, and stores it in a MongoDB.
I expose that data in a REST api. The REST api also exposes resources like batches and other stuff like authentication etc. On top of that I have an AngularJS app, that creates defines the UI.
The one thing that really annoys me, is that I want to globally assign what batch is running. I have a collection of batches, and one of them is the running one. There are a two ways I see to do this, and both illustrate my novice status in the node.js world. All users should be able to see what batch is running, and I want to be able to easily tell from anywhere in the code as well.
1) Set a flag on the object in Mongo. This has a number of problems. The obvious one being performance. I receive sensor data 10 times a second, and I don't want to ask the database every time what batch to save it under.
2) Save the info on the global object. I really don't like this either. I don't like global state in my code.
What is a good pattern for doing something like this? Does my question make any sense?
Thanks in advance
You can make a simple REST call to set the active batch and call it inside the batch when is started up and ready to accept requests. For example:
app.put('/active-batch', function(req, res, next){
// Make sure req.body is defined
app.set('active-batch', req.body);
res.end();
});
Then everywhere in the code you can use:
app.get('active-batch');
The app.set let you save data globally accessible in your app and app.get let you read previously stored data.