npm install
node app.js
- http://apanda-hacking.webflow.io/
- http://apanda-hacking.webflow.io/contacts-analysis
- http://apanda6.co/
| Name | Description |
| ---------------------------------- | ------------------------------------------------------------ |
| **config**/passport.js | Passport Local and OAuth strategies, plus login middleware. |
| **controllers**/api.js | Controller for /api route and all api examples. |
| **controllers**/contact.js | Controller for contact form. |
| **controllers**/home.js | Controller for home page (index). |
| **controllers**/user.js | Controller for user account management. |
| **models**/User.js | Mongoose schema and model for User. |
| **public**/ | Static assets (fonts, css, js, img). |
| **public**/**js**/application.js | Specify client-side JavaScript dependencies. |
| **public**/**js**/main.js | Place your client-side JavaScript here. |
| **public**/**css**/main.less | Main stylesheet for your app. |
| **public/css/themes**/default.less | Some Bootstrap overrides to make it look prettier. |
| **views/account**/ | Templates for *login, password reset, signup, profile*. |
| **views/api**/ | Templates for API Examples. |
| **views/partials**/flash.jade | Error, info and success flash notifications. |
| **views/partials**/header.jade | Navbar partial template. |
| **views/partials**/footer.jade | Footer partial template. |
| **views**/layout.jade | Base template. |
| **views**/home.jade | Home page template. |
| .travis.yml | [Travis CI](https://travis-ci.org/) integration. |
| .env.example | Your API keys, tokens, passwords and database URI. |
| app.js | Main application file. |
| setup.js | Tool for removing authentication providers and other things. |
List of Packages
----------------
| Package | Description |
| ------------------------------- | --------------------------------------------------------------------- |
| async | Utility library that provides asynchronous control flow. |
| bcrypt-nodejs | Library for hashing and salting user passwords. | |
| connect-mongo | MongoDB session store for Express. |
| dotenv | Loads environment variables from .env file. |
| express | Node.js web framework. |
| body-parser | Express 4 middleware. |
| cookie-parser | Express 4 middleware. |
| express-session | Express 4 middleware. |
| morgan | Express 4 middleware. |
| compression | Express 4 middleware. |
| errorhandler | Express 4 middleware. |
| method-override | Express 4 middleware. |
| serve-favicon | Express 4 middleware offering favicon serving and caching. |
| express-flash | Provides flash messages for Express. |
| express-validator | Easy form validation for Express. | |
| jade | Template engine for Express. | |
| lusca | CSRF middleware. |
| mongoose | MongoDB ODM. |
| node-foursquare | Foursquare API library. |
| node-linkedin | LinkedIn API library. |
| node-sass-middleware | Sass middleware compiler. |
| nodemailer | Node.js library for sending emails. |
| passport | Simple and elegant authentication library for node.js |
| passport-facebook | Sign-in with Facebook plugin. |
| passport-github | Sign-in with GitHub plugin. |
| passport-google-oauth | Sign-in with Google plugin. |
| passport-twitter | Sign-in with Twitter plugin. |
| passport-local | Sign-in with Username and Password plugin. |
| passport-linkedin-oauth2 | Sign-in with LinkedIn plugin. |
| passport-oauth | Allows you to set up your own OAuth 1.0a and OAuth 2.0 strategies. |
| paypal-rest-sdk | PayPal APIs library. |
| request | Simplified HTTP request library. |
| stripe | Offical Stripe API library. | |
| twit | Twitter API library. |
| lodash | Handy JavaScript utlities library. |
| validator | Used in conjunction with express-validator in **controllers/api.js**. |
| mocha | Test framework. |
| chai | BDD/TDD assertion library. |
| supertest | HTTP assertion library. |
| multiline | Multi-line strings for the generator. |
| blessed | Interactive command line interface for the generator. | |
You need to have a MongoDB server running before launching app.js. You can
download MongoDB here, or install it via a package manager.
Tip: If you are always connected to the internet, you could just use
MongoLab or Compose instead
of downloading and installing MongoDB locally. You will only need to update database credentials
in .env file.
When I first started this project I didn't have any experience with Handlebars. Since then I have worked on Ember.js apps and got myself familiar with the Handlebars syntax. While it is true Handlebars is easier, because it looks like good old HTML, I have no regrets picking Jade over Handlebars. First off, it's the default template engine in Express, so someone who has built Express apps in the past already knows it. Secondly, I find extends and block to be indispensable, which as far as I know, Handlebars does not have out of the box. And lastly, subjectively speaking, Jade looks much cleaner and shorter than Handlebars, or any non-HAML style for that matter.
For the sake of simplicity. While there might be a better approach,
such as passing app context to each controller as outlined in this
blog,
I find such style to be confusing for beginners.
It took me a long time to grasp the concept of exports and module.exports,
let alone having a global app reference in other files.
That to me is a backward thinking.
The app.js is the "heart of the app", it should be the one referencing
models, routes, controllers, etc.
When working solo on small projects I actually prefer to have everything inside app.js as is the case with this
REST API server.
Absolutely. But unlike a regular footer there is a bit more work involved.
First, delete #wrap and #footer ID selectors and html, body { height: 100%; }
from main.less. Next, delete #wrap and #footer lines from layout.jade
(By the way, if no element is specified before class or id, Jade assumes it is
a div element). Don't forget to indent everything under #wrap to the left
once, since this project uses two spaces per block indentation.
If you would like to use Persona authentication strategy, use the pull request #64 as a reference guide. I have explained my reasons why it could not be merged in issue #63.
Run node setup.js bundled with Hackathon Starter, then select
Email Service option. It will automatically replace appropriate strings in
your code. Currently there are three options: SendGrid, Mandrill, and Mailgun.
Flash messages allow you to display a message at the end of the request and access
it on next request and only next request. For instance, on a failed login attempt, you would
display an alert with some error message, but as soon as you refresh that page or visit a different
page and come back to the login page, that error message will be gone. It is only displayed once.
This project uses express-flash module for flash messages. And that
module is built on top of connect-flash, which is what I used in
this project initially. With express-flash you don't have to
explicity send a flash message to every view inside res.render().
All flash messages are available in your views via messages object by default,
thanks to express-flash.
Flash messages have a two-step process. You use req.flash('errors', { msg: 'Error messages goes here' }
to create a flash message in your controllers, and then display them in your views:
if messages.errors
.alert.alert-danger.fade.in
for error in messages.errors
div= error.msg
In the first step, `'errors'` is the name of a flash message, which should match the
name of the property on `messages` object in your views. You place alert messages
inside `if message.errors` because you don't want to show them flash messages are actually present.
The reason why you pass an error like `{ msg: 'Error messages goes here' }` instead
of just a string - `'Error messages goes here'`, is for the sake of consistency.
To clarify that, *express-validator* module which is used for validating and sanitizing user's input,
returns all errors as an array of objects, where each object has a `msg` property with a message
why an error has occurred. Here is a more general example of what express-validator returns when there are errors present:
```js
[
{ param: "name", msg: "Name is required", value: "<received input>" },
{ param: "email", msg: "A valid email is required", value: "<received input>" }
]To keep consistent with that style, you should pass all flash messages
as { msg: 'My flash message' } instead of a string. Otherwise you will just see an alert box
without an error message. That is because, in partials/flash.jade template it will try to output
error.msg (i.e. "My flash message".msg), in other words it will try to call a msg method on a String object,
which will return undefined. Everything I just mentioned about errors, also applies
to "info" and "success" flash messages, and you could even create a new one yourself, such as:
Data Usage Controller (Example)
req.flash('warning', { msg: 'You have exceeded 90% of your data usage' });
User Account Page (Example)
if messages.warning
.alert.alert-warning.fade.in
for warning in messages.warning
div= warning.msgpartials/flash.jade is a partial template that contains how flash messages
are formatted. Previously, flash
messages were scattered throughout each view that used flash messages
(contact, login, signup, profile), but now, thankfully it is uses a DRY approach.
The flash messages partial template is included in the layout.jade, along with footer and navigation.
body
#wrap
include partials/navigation
.container
include partials/flash
block content
include partials/footerIf you have any further questions about flash messages, please feel free to open an issue and I will update this mini-guide accordingly, or send a pull request if you would like to include something that I missed.
A more correct way to be to say "How do I create a new route". The main file app.js contains all the routes.
Each route has a callback function associated with it. Sometimes you will see 3 or more arguments
to routes. In cases like that, the first argument is still a URL string, while middle arguments
are what's called middleware. Think of middleware as a door. If this door prevents you from
continuing forward, you won't get to your callback function. One such example is a route that requires authentication.
app.get('/account', passportConf.isAuthenticated, userController.getAccount);It always goes from left to right. A user visits /account page. Then isAuthenticated middleware
checks if you are authenticated:
exports.isAuthenticated = function(req, res, next) {
if (req.isAuthenticated()) {
return next();
}
res.redirect('/login');
};If you are authenticated, you let this visitor pass through your "door" by calling return next();. It then proceeds to the
next middleware until it reaches the last argument, which is a callback function that typically renders a template on GET requests or redirects on POST requests. In this case, if you are authenticated, you will be redirected to Account Management page, otherwise you will be redirected to Login page.
exports.getAccount = function(req, res) {
res.render('account/profile', {
title: 'Account Management'
});
};Express.js has app.get, app.post, app.put, app.delete, but for the most part you will only use the first two HTTP verbs, unless you are building a RESTful API.
If you just want to display a page, then use GET, if you are submitting a form, sending a file then use POST.
Here is a typical workflow for adding new routes to your application. Let's say we are building a page that lists all books from database.
Step 1. Start by defining a route.
app.get('/books', bookController.getBooks);Note: As of Express 4.x you can define you routes like so:
app.route('/books')
.get(bookController.getBooks)
.post(bookController.createBooks)
.put(bookController.updateBooks)
.delete(bookController.deleteBooks)And here is how a route would look if it required an authentication and an authorization middleware:
app.route('/api/twitter')
.all(passportConf.isAuthenticated)
.all(passportConf.isAuthorized)
.get(apiController.getTwitter);
.post(apiController.postTwitter)Use whichever style that makes sense to you. Either one is acceptable. I really think that chaining HTTP verbs on
app.route is very clean and elegant approach, but on the other hand I can no longer see all my routes at a glance
when you have one route per line.
Step 2. Create a new schema and a model Book.js inside the models directory.
var bookSchema = new mongoose.Schema({
name: String
});
var Book = mongoose.model('Book', bookSchema);
module.exports = Book;Step 3. Create a new controller file called book.js inside the controllers directory.
/**
* GET /books
* List all books.
*/
var Book = require('../models/Book.js');
exports.getBooks = function(req, res) {
Book.find(function(err, docs) {
res.render('books', { books: docs });
});
};Step 4. Import that controller in app.js.
var bookController = require('./controllers/book');Step 5. Create books.jade template.
extends layout
block content
.page-header
h3 All Books
ul
for book in books
li= book.nameThat's it! I will say that you could have combined Step 1, 2, 3 as following:
app.get('/books', function(req, res) {
Book.find(function(err, docs) {
res.render('books', { books: docs });
});
});Sure, it's simpler, but as soon as you pass 1000 lines of code in app.js it becomes a little difficult to navigate the file.
I mean, the whole point of this boilerplate project was to separate concerns, so you could
work with your teammates without running into MERGE CONFLICTS. Imagine you have 4 developers
working on a single app.js, I promise you it won't be fun resolving merge conflicts all the time.
If you are the only developer then it's fine. But as I said, once it gets up to a certain LoC size, it becomes
difficult to maintain everything in a single file.
That's all there is to it. Express.js is super simple to use. Most of the time you will be dealing with other APIs to do the real work: Mongoose for querying database, socket.io for sending and receiving messages over websockets, sending emails via Nodemailer, form validation using express-validator library, parsing websites using Cheerio, and etc.
Dan Stroot submitted an excellent pull request that adds a real-time dashboard with socket.io. And as much as I'd like to add it to the project, I think it violates one of the main principles of the Hackathon Starter:
When I started this project, my primary focus was on simplicity and ease of use. I also tried to make it as generic and reusable as possible to cover most use cases of hackathon web apps, without being too specific.
When I need to use socket.io, I really need it, but most of the time - I don't. But more importantly, websockets support is still experimental on most hosting providers. As of October 2013, Heroku supports websockets, but not until you opt-in by running this command:
heroku labs:enable websockets -a myappAnd what if you are deploying to OpenShift? They do support websockets, but it is currently in a preview state. So, for OpenShift you would need to change the socket.io connect URI to the following:
var socket = io.connect('http://yoursite-namespace.rhcloud.com:8000');Wait, why is it on port 8000? Who knows, and if I didn't run across this blog post I wouldn't even know I had to use port 8000.
I am really glad that Heroku and OpenShift at least have a websockets support, because many other PaaS providers still do not support it. Due to the aforementioned issues with websockets, I cannot include socket.io as part of the Hackathon Starter. For now... If you need to use socket.io in your app, please continue reading.
First you need to install socket.io:
npm install socket.io --saveReplace var app = express(); with the following code:
var app = express();
var server = require('http').Server(app);
var io = require('socket.io')(server);I like to have the following code organization in app.js (from top to bottom): module dependencies,
import controllers, import configs, connect to database, express configuration, routes,
start the server, socket.io stuff. That way I always know where to look for things.
Add the following code at the end of app.js:
io.on('connection', function(socket) {
socket.emit('greet', { hello: 'Hey there browser!' });
socket.on('respond', function(data) {
console.log(data);
});
socket.on('disconnect', function() {
console.log('Socket disconnected');
});
});One last thing left to change:
app.listen(app.get('port'), function() {to
server.listen(app.get('port'), function() {At this point we are done with the back-end.
You now have a choice - to include your JavaScript code in Jade templates or have all your client-side
JavaScript in a separate file - in main.js. I will admit, when I first started out with Node.js and JavaScript in general,
I placed all JavaScript code inside templates because I have access to template variables passed in from Express
right then and there. It's the easiest thing you can do, but also the least efficient and harder to maintain. Since then I
almost never include inline JavaScript inside templates anymore.
But it's also understandable if you want take the easier road. Most of the time you don't even care about performance during hackathons, you just want to "get shit done" before the time runs out. Well, either way, use whichever approach makes more sense to you. At the end of the day, it's what you build that matters, not how you build it.
If you want to stick all your JavaScript inside templates, then in layout.jade -
your main template file, add this to head block.
script(src='/socket.io/socket.io.js')
script.
var socket = io.connect(window.location.href);
socket.on('greet', function (data) {
console.log(data);
socket.emit('respond', { message: 'Hey there, server!' });
});Note: Notice the path of the socket.io.js, you don't actually
have to have socket.io.js file anywhere in your project; it will be generated
automatically at runtime.
If you want to have JavaScript code separate from templates, move that inline
script code into main.js, inside the $(document).ready() function:
$(document).ready(function() {
// Place JavaScript code here...
var socket = io.connect(window.location.href);
socket.on('greet', function (data) {
console.log(data);
socket.emit('respond', { message: 'Hello to you too, Mr.Server!' });
});
});And we are done!
Copyright (c) 2016 Apanda