Express.Js, Node.Js, MongoDB Questions [closed] - javascript

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'd like to try out some of the new technologies available for doing web development. I've been using php frameworks, rails and asp.net mvc for quite some time now and I saw that Node.Js provided a lot of good stuff to the table.
But I don't know how and where to begin. I setup mongodb, node.js and express.js and I played with it a bit but I'd like to know how to make the link between express.js and mongodb (I have mongoose but I don't know how to include it yet) and I'd like some brief and simple examples (unlike stuff that is in express.js docs) to see some actual usage cases.
I'd like to build some quick content management system and with a simple frontend, and I wanted to make a change and try that out. Any advice and help will be appreciated!
[edit: I already read http://howtonode.org/express-mongodb it helped but it doesn't explain much about how to do it]
Thanks!

Here's a get started blog post for Node.js + MongoDB. You can easily ignore the Cloudfoundry stuff. Mongoose is a layer over the basic driver, so you should probably start with the basic driver.
If you want some code / ideas to steal, take a look at railwayjs.

Start simple. Code a basic web site using vanilla node.js standard library HTTP module (require('http');). Learn the basics of the http request and response interfaces, especially the evented interfaces for streaming data. Learn the basic fs module and how to take plain .html files on disk and send them as HTTP responses. You can do this in a single .js file without needing any third party npm modules. Full stop until you have that done and it makes sense to you. If something isn't clear, experiment until it is (and ask more questions here). This is straightforward, but there are still lots of ways to get confused.
Once you have that, you'll see that it's actually already pretty high-level and straightforward to write a small web site. Next add express.js. Study the concept of connect middleware and how the middleware chain works, including the next callback, bodyParser, and static middlewares. Make sure you understand why middleware often needs to be applied in a specific order and how it breaks if you apply them in the wrong order. Understand express's app.error, dynamicHelpers, and most of the examples in the documentation, which are all very good and realistic but I agree because they are just tiny snippets they leave a lot of room for questions about the surrounding context and how things fit together entirely. Don't go nuts with complex layouts and templating stuff, just stick to the basics.
Then maybe start persisting some domain level data into simple files on the filesystem, perhaps just .json data. This will present new challenges and help you understand more complex things in an async world. In particular, if you start having to do a series of operations like recursively ensure a directory path exists and then write a new file in the final leaf directory, you will want to look at a flow control library like async or async.js or similar.
Only then should you start adding mongoose and mongodb to your stack and replace your fs.writeFile calls with mongoose model.save calls.

For me the biggest help I found when experimenting with all these awesome new technologies was looking at this sample application:
Demo App - https://github.com/madhums/nodejs-express-mongoose-demo
It shows some good usage of how to organise a node-express application, some common utilities for showing mongoose validation errors messages, stylus for css, jade views, etc. And the author appears to take requests if you think something should be added to the demo app to help others learn a new express/mongo/etc feature - I haven't asked personally but there is a check-list on the github page showing what features are completed and what's upcoming.
I would also recommend just getting your hands dirty :) Come up with a simple idea and try to build it. And when something doesn't feel right or you have a block then there's a pretty amazing and growing community out there.
Here are some tutorials not mentioned above:
Mongoskin (mongoose alternative) - http://www.hacksparrow.com/mongoskin-tutorial-with-examples.html
Exress JS tutorial: http://www.hacksparrow.com/express-js-tutorial.html
Also if you go to the github page for expressjs you will see many examples of specific express functionality - which goes into some great specifics:
Express js examples: https://github.com/visionmedia/express/tree/master/examples

Related

Should I use two seperate projects for frontend/backend in addition with API or merge them to one? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have a few questions which I'd appreciate to have some answers on.
So I've created a backend node server with express & mongo which is running specific tasks on the net and saves it in the database in a loop. I've also added an admin page with express & bootstrap. And that works fine. What I needed then was a frontend page - for this I chose VueJS. I started that project seperate for multiple reasons. I felt that this would be easier to get started, since I didn't have any frontend framework experience before and the backend project was written in typescript and I'd rather use normal es6 JS for now.
Right now - the site has already made some pretty decent progress and is at the point where I need to establish connection with the database and also use some of the already implemented functions in the backend project.
And this created the question:
Should I create new functions and/or create and use API's? Would there be any problem with the mongodb in the form of accessing and writing to it by two different processes? Would there be security issues if I'd create "public" apis from my already existing backend logic? (Haven't written any apis yet.)
Or should I use the time and import the frontend project into the backend (meaning also either translating new to typescript or switching to normal ES6 JS)? Would this be a security risk since I'd rather not have the backend logic in my frontend site.
I appreciate any answer to that!
Thank you :)
This is a question of can you afford to run two servers? separating your front end from your back end is actually a good move considering all things microservices since it allows you to scale these things separately for future purposes. Like your backend needing more resources once you start catering to mobile user as well or once you get more api calls, while your front end server need only serve the ui and assets, nothing more. Though the clear downside is the increase in costs since you do need to run two servers instead of one, something that is difficult when you are just starting out
Should I create new functions and/or create and use API's?
For your backend? Yes. APIs are the way to do things now in the webspace as it future proofs you and allows a more controlled and uniform way to access your backend(everything goes through the api). So if your front end isnt accessing your database through the APIs yet, i suggest you refactor them to do so.
For your concerns about mongo, im pretty sure mongo already has features in place to avoid deadlocks.
As for security of your API, I suggest checking out JWT.
should I use the time and import the frontend project into the backend
should you go this path instead due to cost concerns, i would suggest rewriting one of the codebase to comply with the other for uniformity's sake, though do that at your leisure(we can't have you wasting all your precious time rewriting code that already works just fine). this isnt really that much of a security issue since backend code isnt being sent to the front end for all your users to see
Let me start by saying I've never used Vue. However, whenever I use react, I always make separate projects for the front end and the back end. I find it's 'cleaner' to keep the two separate.
I see no reason for you to transcribe your entire project from typescript. Simply have your frontend make requests to your backend.
If you're looking to brush up on your web security, I recommend you look into the Open Web Application Security Project.

Is Node.js suitable for my project given how I'm using it?

I'm about to start writing an application and I want to include newer technologies to improve my knowledge and gain a skill set.
I'm using mysql to store user data (no choice), Angular.js to display/template content on the dom, and I wanted to use node.js to return results from the database in json format to be used by Angular.js.
My assumption was I could use node.js (along with the node-mysql module and maybe express)to accomplish my database queries that feed into my Angular.js templates.
Additionally, the application will live on a different server than the database itself and may reside in a mobile framework.
Am I way off base when it come to how to use node.js? Am I just using the wrong tool? Am I on the right track?
Any help, explanation, and points in the right direction would be great. Most of the info I've seen are copy/paste from the node.js site/wiki and don't really answer my question.
This is largely an opinion-based question and likely to be closed, but you're not way off base. What you want to do is absolutely (and commonly) done using Node.js.
As a complete aside, you might like to check out Platform-as-a-Service providers such as Heroku.com and Nodejitsu.com; both offer great and easy Node.js hosting and addons (such as NoSQL and RDBMS data stores) which have free tiers.
For that matter, MongoLab and MongoHQ both offer free tiers independent of Heroku, which you could use from your MySQL-only hosting provider if you like.

Is it already worth to give Derby.js or Meteor a shot for an app for production with authentication? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I started reading about Derby.js and Meteor to do some research on an project I'm working on. It uses a lot of real time functionalities so they both seem handy. But I have some major concerns and am wondering if it makes sense to use them at this time.
Are they yet production ready? Or are there still major security issues?
Do they by now support sessions and authentication?
Am I right with the assumption that by relying on frameworks that do a lot of the work you might have it easier for the simple stuff but much, much harder if it get's a bit more complicated?
Am I right with the assumption, that I could achieve exactly the same effects (from a user-experience perspective) when I just use Express + Socket.io (or express.io) and that I just have to invest more time/work?
At the moment I'm more drawn to Express + Socket.io and think Derby and Meteor are a bit hyped. What do you think?
To get a better idea of what I'm planning:
User authentication is needed
Complex routing is needed
SEO is an issue
Full Text Search using Elasticsearch
DB probably MongoDB
Complex relations between objects
Realtime updates (Socket.io)
Security is an issue
Performance and scalability are issues.
Thanks!
I can answer your questions for meteor:
YES. There are many of us running meteor in production for revenue-generating companies.
YES. Meteor has had an accounts system since October of 2012.
The more the system does for you, the harder it is to manipulate the underlying mechanics. I find that meteor strikes a reasonable balance.
This assumption is correct. You could also implement your own web browser to visualize HTTP, however I find it easier just to use chrome.
Other Requirements
User authentication: Yes, see above.
Complex routing: Yes, see iron-router and flow-router.
SEO: Yes(?), see spiderable and ssr and this post.
Elasticsearch: Yes, (independent from your framework choice). Meteor doesn't have an ES backend, but you certainly can talk to an ES datastore via a node.js module or directly over HTTP.
MongoDB: Yes, that's meteor's default (and only official) DB.
Complex relations: Yes, (independent from your framework choice).
Realtime updates: Yes, this is how meteor works.
Security is an issue: Yes, Emily Stark has you covered! Also see this post on the discover metetor blog.
Performance and scalability: Use oplog-tailing and monitor your app with kadira.
There are Meteor answers and there should be for Derby too:
Yes, from 0.6 version Derby is stable enough and there are some sites using it in production, ex: Lever.
Yes, there are some auth modules, ex: derby-login which uses passport
Yes, but the more modular framework is (consist of replacement parts) and the more it follows conventions (npm, Express etc), the less you feel it.
Yes and no. For example if you are serious about realtime, it's better to have some conflict resolution mechanism (OT or CRDT or smth else) and it's not trivial to implement one. By the way, Meteor does not have any, it uses LWW-strategy.
Other Requirements
User authentication: Yes, there are some modules.
Complex routing: Yes, isomorphic Express-like router.
SEO: Yes, built-in isomorphic (client and server) template engine. Html for first request renders on server, for subsequent url-changes it renders on client.
Elasticsearch: Yes, certainly. That's not framework issue.
MongoDB: Yes, there is adapter for it and this is the best choice for the moment.
Complex relations: Yes, not framework issue.
Realtime updates: Yes, with OT.
Security is an issue: Yes. From server perspective Derby is just Express. To secure all these realtime comunications, use some access-control module, ex: share-access
Performance and scalability: Yes, I do not have tests, but theoretically Derby should be more performant while scaling than Meteor. There is a kind of confirmation.
What about Meteor, I used it before Derby. It has good documentation, tutorials, support and marketing. It's good to bootstrap a small app in five minutes. It's good to understand concepts like: db on client, isomorphic code, realtime, etc. But it's quite monolithic and not flexible. It's way of implementing realtime is very simple, but it lacks of conflict resolution and have issues with performance. It can not be used for offline in any sensible way. Most of Derby-developers came from Meteor.
Try both and make a choice. Good luck!
I agreed with almost all answers from #David Weldon, just a few things you need to consider: Complex relations and scalability.
When you say complex relations between objects, I'm wondering if MongoDB is the RIGHT choice for you. Since all data is stored in documents, the less relations between the Collections the better.
On scalability, as said above, if you have a few rather "relational" collections (MANY-TO-MANY etc.), you could run into serious scalability problems in future (hard lesson learned).
If you really do, you should wait until Meteor officially supports other RDBMS.

Best practices of building a website using Node.js

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I was wondering how one would go about developing a website from scratch with Node.js.
I understand how I could possibly do it, but I am interested in the best design practice.
I need this theoretical website to:
Do a lot of AJAX
Be very straightforward
Be relatively small
Connect to... let's say a MySQL server
In PHP, building a pretty small website was very straightforward - I set up PHP on Apache and a MySQL server and then do something like:
includes/db/ which has connect.php for connecting to the db, a file with common db related functions and so on
includes/layout/ which had stuff like footer.php, header.php, and other layout related stuff
includes/users/ to handle user related actions
Then PHP just let you build pages and include these files together to form a website - I could go something like:
<?php
require_once('inclues/users/user_session.php');
require_once('inclues/db/connect.php');
require_once('inclues/design/header.php')
?>
// Other php or html or related content relating to the page
<?php
require_once('inclues/.../footer.php');
?>
I was wondering what might be similar in Node.js - I am looking for a way to accomplish this which is as simple, fast and straightforward as possible.
If the answer is not simple, I would love a book recommendation, I don't mind reading.
I love event based programming, I really love JavaScript's abilities and I'm really excited about Node.js. I want to learn how to develop this sort of stuff with it the right way from the start.
To start with the bad news: As Node.js is a pretty young technique, I think you'll find that the proces of creating a full fledged website and maintaining/operating it will be very different than what you're currently used to.
Josh3736 adds: Once you figure out how Node.js and its various packages (Connect, Express) work, I found that you can develop new sites very quickly.
The rough edges that currently exist in Node.js, combined with the fast pace of its development and all modules involved can complicate things though, and make things less simple, fast and straightforward than you'd like.
Having that out of the way, here's the good news:
The Node Package Manager, NPM has a lot of good tools and frameworks to expand Node.js's bare bones functionality, making it suitable to create a webserver.
Most notably would be the Express Framework which contains almost everything you need to run a webserver (including cookies, sessions and path routing). Additionally Express supports partials, which take care of your header and footer includes.
Express is built on top of Sencha's Connect. Cookies and sessions are actually powered by Connect. Express is what simplifies your routing and handles views/partials. So if you don't need all bells and whistles that come with Express you could just go for Connect instead.
If you like to use templates for these partials, the Jade Template Engine can speed things up for you. Though Josh3736 points out that Jade is slow and whitespace-significant. A more complete overview can be found here, which includes his favourite, doT. (I personally use Node.js for socket.io based applications only, so he's a better source than me when it comes to templating).
You can connect to MySQL from Node.js using the db-mysql module, but if you don't need that because you're accessing data connected to an already present system, I'd advise to use a more... 'modern' approach, which is to use a NoSQL database as most Node.js projects seem to do. MongoDB via Mongoose is the popular way to go.
Or if it's just storing objects you're interested in, just go for Redis instead (which you're probably going to need at some point anyway).
Once your website is complete, you'll have to deploy it and make sure it keeps running. There are many ways to do so, like using built-in cluster support or use the more feature-friendly forever npm module. See this SO question of mine for more information.
Conclusion:
What I'm trying to get at is this:
Asking what the best practice for building a website in Node.js is, is about the same as asking what the best way to build a website in PHP is: 100 developers will give you 100 different answers.
NPM is blessed with a variety of excellent frameworks that greatly simplify a lot of tasks involved, but it's all based on preference which one is the way to go really.
As I've said, Node.js is still a pretty young technique, so none of the frameworks or additional tools have emerged as 'defacto standard' yet; for most things you're trying to do there are probably various alternatives, and expect your code to break when using most of them during updates, because development of Node.js itself and most modules is fast paced. You'll have to keep up.
Putting it all together:
As I've said, my main production use for Node.js is to be able to use socket.io, so I don't have any good production examples present (And as I'm about to leave on a well-deserved vacation I don't have the time to put one together either). There are some good examples though:
Setup and deployment using Express and Jade
A very complete blog example using Express, Jade and MongoDB
Combining Restify (an extension of Express), Backbone.js and Mongoose
Again, the way to go (and subsequently the example to follow) depends greatly on your ultimate goals and the techniques chosen, but luckily there are plenty of resources available for all of the choices available. Most modules use well documented GitHub repositories and include examples in combination with the most popular modules (See the /examples/ dir that seems to be present in most repositories).
(thanks to Josh3736 for rectifying my errors.)

How should I create a web interface for my application? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
First, a little background: I have written a little application in python with SQLAlchemy, which is roughly an improved RSS reader: it selects links that should interest the user, and shows them to him. I already have a very simple command-line interface, and I envision a variety of interfaces: web, instant-messaging, desktop...
For now I'd like to create a simple web interface, but I have absolutely zero experience in the matter (appart from making a simple php forum 5 or 6 years ago...). So I'm comming here for advice on where to start:
Is there a good tutorial on HTML/CSS/Javascript focused on making a website look good simply? I know about w3schools, but it's a terrible tutorial IMHO, since it teaches you about HTML/CSS but doesn't show you how to use them.
Should I use a javascript library? Which one?
Should I use a web framework? I'm guessing either not or a very lightweight one, since I already have an application core with a database and SQLAlchemy, and I don't want to drop it.
Any other advice?
Thanks!
I recommend that you use some kind of web framework, it will make things a lot easier. Since you already know Python you should look into Django framework. It seems that you can use SQLAlchemy with Django, see djange-sqlalchemy project.
I recommend using JQuery framework/library for Javascript stuff. It greatly simplifies coding and takes care of most web browser incompabilities.
This CSS tutorial seems to give you the basics.
I would start by reading the Django tutorial and start trying things out. I wouldn't worry too much about HTML stuff, you should be able to pick up enough from Django tutorial. Make your site first functional with HTML, Django and SQLAlchemy. Only then start worring about Javascript. Who knows, maybe you do not need Javascript at all?
Do not try make your site work and look good at the same time. When you are making your site work, use simple and ugly HTML pages. When you are making you web site look good, work only with static HTML pages and CSS files. It is easier to combine the two in the end.
Just like everyone else here, I'll chime in with "Use my favorite framework, because it's what I use...."
I would start with small goals for a web interface. Get something simple up and running that to make sure you understand how things work.
Write an app that responds to the following url and returns something.
http://localhost:8000/my_links
Once you understand the little bit of machinery it takes to make that possible, what is handed to you as far as information about the request, and what you need to produce to return to the caller, it should be come clear how to fill in the blanks to get from your existing application to data thrown at the web browser.
Learn WSGI for no other reason than most of the libraries that will help you build a web application utilize this to some degree.
One of the links from the above page that I found extremely beneficial in understanding how all this works. was Ian Bickings article "A Do-it Yourself Framework"
Once you get a grasp of that stuff, you may find that dealing with WSGI at such a low level is maybe a little too cumbersome. That's when you'll probably want something like WebOb
which is just one of several ways people have come up with for abstracting away the low level details of the request/response cycle into some convenient objects. In a sense encompassing the HTTP protocol without trying to make it make sense to someone who doesn't want to know what HTTP is.
Depending on the complexity of your application you may decide that handling a request, looking at the path and dispatching off to one of many functions is a drag you'd rather not deal with. This is where everyone's favorite framework starts to be beneficial. And I would suspect that you would know enough by this point to better assess the frameworks that are out there and determine which fits your needs and goals.
Lots prefer django, maybe you will too. Others prefer Turbogears, and or Pylons, maybe bfg, maybe grok, maybe zope, maybe plone. But no one here knows what you want your application to do.
It's an interestingly common mistake: all of the above answers provide technological advise on what's the best technology to do ... what exactly? You should work the other way around.
I think that if you want your application to be successful, you have to make sure it enables its users to get the most out of it in the most natural way to them.
Therefore, i suggest you first "storyline" how things should happen from a user's perspective. Use paper and pen, or more sophisticated wireframing tools such as balsamiq mockups.
So, first lay out what the experience should be, and this will tell you which technology will be the best choice to enable that experience.
Oh, and don't forget to read this.
HTML, CSS and JS Book: DHTML and CSS for the World Wide Web
Javascript Library: JQuery
Web Framework: Not sure, DJango?
Other Advice: Learn to write HTML, CSS, and JS in a a simple text editor with syntax highlighting. Complex IDE's are cool, but for this stuff, they will make you learn slower.
Web applications are not simple.
HTML and CSS: Head First HTML is probably a good starting point. The Head First series are usually excellent tutorials. As Josh said, write your pages by hand.
Javascript: you don't need this to get started. Maybe in a later version. When you have a better idea what you'll need Javascript for, you'll be better equipped to pick a library that suits your needs.
Web framework: You should probably start with Django. That's the opposite of a "very lightweight" framework, but in this context "lightweight" requires more expertise to make something polished. So it's a good idea to aim for "feature rich and well supported" instead.
Here is another option, I feel it's worth mentioning before making any decision.
As web framework I would advise web2py, it is very easy to setup and yet powerful. Here is a document showing the differences between Django, web2py and some others. It is somewhat old but will give you a good overview.
Since you have legacy code, if you really want to keep it there is a fair compatibility between the two although you should double-check. The easiest would be to adapt your code, of course, the differences aren't so big. But that's your call :-)
Regarding the Javascript library, probably jQuery.
The best introduction you could follow is the opera web standards curriculum. Some of the information will be too basic - but a full understanding of all the topics covered will give you a very good grounding.
http://www.opera.com/company/education/curriculum/
Alternatively team up with someone who specialises in front-end development.

Categories

Resources