Searching for such framework results mostly in Passport.js which I think is only good for authentication.
In PHP world, there is Sentry Cartalyst which is good for
Authentication
Authorisation (groups)
List item
User activation
Password resetting
Throttling
Is Node.js not mature enough to have such full-fledged open source framework?
node.js is built upon modules, which are built upon modules, etc. Frameworks in the normal sense don't really exist. Instead, what you have are starting points for applications, usually called Generators, and then you have modules that implement functionality. Generators of course are not required, you can instead start from scratch.
There are a few modules that do so much for you that they feel like frameworks, but at the end of the day they're just part of a whole, a module, that extends an existing module. Express is a great example of that. It wraps http.Server and handles the request callback for you, allowing you to chain callbacks onto a single request callback (called middleware) that eventually result in responding to the client with data (through routing).
But, all express does is routing. it doesn't do templating, emails, db work, authentication, data modeling, nothing. That all has to be added as middleware, and is usually done by using existing modules that implement that functionality.
Now, back to generators. Probably the most popular generator out there for Express is the express generator, however, all it comes with is express, a few essential pieces of middleware, error handling, and a templating engine. You're left with the task of installing and implementing other parts of the application (such as authentication) yourself. This is normal with node.js. At this point you would need to decide what you need for your app, how you want it implemented, and then find modules that accomplish those goals (or write modules yourself, because often times one doesn't exist that does precisely what you want.)
I said I wouldn't do this, but, Loopback is another module and generator (the loopback devs call it a framework, I call it a generator, whatever) that builds an express app (wrapped in the loopback module), but it has almost all of the things you are looking for built-in. I don't use it because I feel it does too much. When my application was built with it, I felt uncomfortable with not knowing how the majority of the application worked, because I didn't build it, I just plugged in my data. It certainly saved time up front, but when it came to doing custom work that wasn't supported out of the box, it became very time consuming.
If you're looking for a full CRUD user management system, you can't really beat something like Stormpath.
Using their express.js library instantly gives you a full CRUD system (with Node / Express / Restify / Loopback / Python / Django / Flask / etc...) libraries for managing / working with your users.
Here's their express.js library docs: https://docs.stormpath.com/nodejs/express/
Essentially, what they do is:
They'll store your user accounts.
You use their middleware to create / login / manage users.
You can use their middlewares to restrict pages by login, group, API authentication, etc.
You can use their libraries to search / sort / create / update / delete users / API keys / applications / groups.
It's very feature complete, and well documented.
I'm the author of the above library, so I'm a bit biased, but it's honestly quite useful =)
Related
i want to create a website based on node js and mysql , but i've read that there is a framework called express for node js , and i'm wondering if i must to use such kind of a framework to create a decent website or it is possible without it and just work with pure node js.
No framework is required. You can write a full-blown web server using only the http module or if you really want to write everything yourself, you can even do it with only the net module.
It's really about what is the most effective use of your time and skill as a developer. Except for academic or pure learning experience reasons, if you're just trying to accomplish a task as efficiently as possible and free, pre-existing, pre-tested code exists that makes your job easier, then that's a better way to go.
For example, if I need to do a file upload from a browser to my back-end and the data is coming in as the multipart/formdata content-type from the browser, I have zero interest in reading and learning the multipart/formdata RFC then writing my own code to parse the multipart/formdata content-type. Pre-existing, already tested code exists to do that for me and I'm adding no value to the goals of my project by re-implementing and then testing it all myself. Therefore, I'd like to use a pre-built module that does all that for me. I can just configure the right library on the right route and out plops my uploaded file in only the amount of time it takes to understand the interface to the 3rd party module and how to use it properly.
This is where Express comes in. Not only does it offer a useful set of features and architecture for configuring routes, installing middleware, sending responses, using template engines, handling errors, etc... but there are also thousands of third party modules that are built to hook into Express and it is easiest to use them if you're using Express as your core framework. Some of these modules could be used outside of Express, some cannot - it really depends upon how they're designed and what Express interfaces they do or don't use.
Also, Express is fairly "un-opinionated" and fairly "lightweight" which means it doesn't force you into a particular methodology. It just offers you easier ways to do things you were already going to have to write code for yourself.
Look at it this way. When you get node.js, there are thousands of APIs that offer lots of already tested things such as a TCP library, a file I/O library, etc... Those are frameworks (in a sense) too. You don't have to use them either. You could rewrite whatever functionality you need from scratch. But, you wouldn't even think about doing that because tested code already exists that solves your problem. So, you happily build on top of things that are already done.
One of the BIG advantages of coding with node.js is getting access to the tens of thousands of pre-built modules on NPM that already solve problems that many people have. Coding in node.js with a mindset that you will never use any outside modules from NPM is throwing away one of the biggest advantages of coding with node.js.
could you tell me what are the Routes used for in frameworks?
A route is a URL that you wish for your web server to respond to. So, if you want http://myserver.com/categories to be URL that your server responds to, then you create a route for /categories so that you can write code for what should happen when that URL is requested. A framework like Express allows you to create that route very simply with just a single statement such as:
app.get('/categories', function(req, res) {
// put code here to handle that request
});
This is just the tip of the iceberg for what Express supports. It allows you to use wildcards in route definitions, identify parameters in urls, create middleware that does prep work on lots of routes (such as check if the user is logged in), etc...
You don't have to use a framework but it is recommended to use one of them since frameworks like Express make your life easier in many ways. Check this: What is Express.js?
Yes you CAN write a Node.js-based backend without any back end implementation framework such as Express. And if you are using Node.js for the first time without any previous experience of asynchronous coding, I'd advise against using Express, KOA or other Node implementation frameworks for your simple learner apps (e.g. those needing things like register/login form processing, logout button, user preference updates to database, etc) because:
(1) Node.js is a core skill for JavaScript back ends.
Stupid analogies between server tasking and restaurant waiters are no use to a real web engineer. You must first know what exactly Node can/cannot do in the server CPU that makes it different to most other back end technologies. Then you have to see how the Node process actually does this. Using Express/KOA/Hapi/etc you are sometimes effectively removing the mental challenges that come with a Node back end. Any time-saving is achieved at the expense of gaining a proper working understanding of what Node is and how it really operates.
(2) Learning Node.js and its asynchronous coding is hard enough without the added complication of coding with an unknown framework like Express/KOA that assumes users' familiarity with JavaScript constructs like callback functions and Promises. It's always better to learn something in isolation so you get the essence of its individual effects, rather than the overall effects if used with other packages/frameworks. So many of these Node.js Express tutorials are the software equivalent of learning to make a cake by watching Momma do it. We can copy it but we don't know how or why it's working. Professional coders can't just be good copycats.
(3) Available learning tutorials using Express often drag in other technologies like MongoDB, Mongoose, Mustache, Handlebars, etc that make learning Node.js even more awkward still.
(4) A share of basic web apps can be written more efficiently with Node.js, custom JS and existing JS modules imported off the npm repository rather than with Express.
(5) Once asynchronous coding and the JavaScript constructs available to assist with it are understood clearly, pure Node.js apps for basic tasks aren't that hard.
(5) After you do get your head around Node.js and can get basic web app functionalities working using server-side JavaScript constructs, you can then judiciously start to explore Express/Hapi/KOA/etc and see what an implementation framework can do for your workflow when doing larger projects needing numerous functionalities. At this point you know what Express code should be doing and why it is done the way it is.
Node.js has become the back-end technology of choice for most small to medium scale web applications over the last 10 years. It is also the major reason why the JavaScript language has evolved from a mere front-end scripting tool with a limited set of Java-aping constructs to the innovative and comprehensive language that it is today. It is also the most popular language in use today. Investing time in understanding the Node server framework, and the latest JavaScript constructs used in Node, is time well spent. Implementation frameworks such as Express, KOA, Hapi, Sails, etc have great benefit when writing more elaborate back ends on the Node.js platform. But all these implementation frameworks are predicated on the behaviour patterns of Node.js. So unless Node itself is understood first, the full utility of Express/KOA/Sails/etc will never be enjoyed.
Try here for the pure Node.js.
My team has developed an iOS and Android App for our project while we use node and socket.io for back-end. We want to move to meteor so we can have a front-end with Angular 2 easily connected with the back-end.
But we want to rewrite the back-end with Meteor so our Apps can use it. And after this create the front-end.
My question is easy, in Meteor front-end and back-end are done at the same time? Or can we first build the back-end and after this the front-end?
Yes, this is possible although it would feel a bit awkward to an experienced Meteor developer.
The Meteor "back-end" exposes the following:
managed collections: these are the definitions of the mongodb collections that will be used by your app to persist data. Note that some of these can be private to the back end, i.e. not exposed to the front end at all.
publications: these are the filtered/projected "views" of the collection data that the back-end will share with the front end on request (the form of the request is a subscription). Published data is synchronized bidirectionally with the front end asynchronously over WebSocket. This is the magic of Meteor's DDP which IMO is Meteor's core innovation.
methods: these follow a more traditional request-response pattern. You can have as many of these as you want and each can accept any number of parameters including objects. Meteor can also do latency compensation for methods which means that the method is first simulated on the client and the UI updated while waiting for the server to come back with an authoritative result. If the server result differs then the UI is patched up with the authoritative result. This makes database updates appear instantaneous to the user while providing eventual consistency.
If you like you can even build traditional REST endpoints with Meteor but then you would be missing out on the reactive sugar. These can of course be useful for other integrations however.
Like nodejs, Meteor encourages developers to tackle the full-stack. You're less likely to segregate developers into back-end and front-end functions which gives you a lot more flexibility.
I am now building a native mobile application in Nativescript, leveraging my JS knowledge.
So, I though to switch to some other Nodejs framework.
My app's backend requirements will be:
pure JS
complete backend logic (i.e. controller)
connect to a MongoDB database
RESTful
non-frontend-dependent
non-DOM-dependent
easy-yet-complete to use: should be a framework which gives strong foundations to make a solid and efficient backend for a (relatively) inexperienced backend developer (except for Java basics and experience with pure PHP)
I was considering using my existing knowledge of Meteor but I can't implement any existing experiment of using ddp and websockets in it.
Some of the possibilities I was considering to give a try to:
Loopback
Total.js
Hapi.js
Sail.js
I am fine with any JS-based framework, whether it's NodeJS based or not
I am also open to a REST API solution which exposes Meteor backend, as long as is doesn't require ddp to be usable (it's not very clear to me what are the limits of non using DDP when using Meteor)
Any concrete advice, which would eventually avoid me trying all of them, before discovering they don't work with Nativescript or don't satisfy my requirements?
SailsJs is a wrapper around express.js with many add-ons and shortcuts that eases your life and shortens the code required to write, and it's very much suitable to write RESTful apps.
HAPI and Total, I didn't use them myself, but there are very good reviews about them, but when it comes to Sails, it's the highest in popularity, hence, better tested and used, which leads to a more mature framework over the time.
Loopback is good, but it requires payment at some point of usage, and still Sails is more popular.
Meteor.js is great, but it's not the right tool for that job, and it might take you more effort to make it as an easy to use RESTful framework, not to mention the un-needed memory and processing overhead, which has it's uses, but not in RESTful case. I tried to use it to write RESTful apps but didn't feel the ease and the low memory footprint as I experienced with express and Sails.
Update
Sails has clear and easy to use MVC style, with a command line to generate apis, configure-and-fine-tune-later APIs style, which is very much needed in prototyping and PoC applications, as well as short time to market.
Update 2
Sails ORM supports both SQL and NoSQL DBs, with dozen of supported drivers out there
I'm new to the full stack javascript application development, have read a lot of posts and documentation to all sorts of things but am a bit stuck on the following issue:
There are two frameworks that seem to offer quite similar functionality but are never contrasted against one another on the internet (as far as I could tell)
SailsJS - server side MVC framework built on Express
BreezeJS (+AngularJS) - client side MVC
Apparently I can combine Sails with Angular, there are a few attempt in NPM but none using Breeze in addition, is that due to redundancy or is it just a stupid idea?
I was thinking of developing a SPA that has computation intensive backend processes ( e.g. machine learning on large data sets ~ millions of mongo documents ) on something like
Mongo - Node : { Express - Sails } - Breeze - Angular
I'm looking for feedback on whether this kind of stack (particularly the Breeze / Sails part) is a bad idea or not. Also I'm really thankful for any advice / links to advice on javascript full stack architecture design decisions.
Thanks!
Basically, all the software you have mentioned can be used in one product. It's the important though to understand the purpose/strength of each component:
1. MongoDB
This one is pretty clear: database engine.
2. Node.js
This one too: server-side Javascript which will power your API.
3. Express.js
Now it's getting more interesting. Express is a server-side web-application framework for Node.js, but a very minimalistic one, which means it provides some basic functionality, no hidden magic and other fancy stuff.
4. Sails.js
On the contrary, Sails provides a lot of magic, starting with the API out of the box and ending with sockets. Even though it's built on top of Express, Sails is a server-side Javascript framework which follows a completely different approach, with convenience over simplicity. If we talking about a SPA, then the most useful thing Sails has to offer is, definitely, API out of the box: you'll be able to get it up and running in less then 5 minutes.
5. Angular.js
Here we are getting onto the client side. Angular helps you better organize your client-side Javascript and easily perform some pretty complex tasks in the browser. And, of course, Angular (or a similar framework, like Backbone, Ember, Knockout, etc.) is a must-have nowadays if we are talking about rich client applications.
6. Breeze.js
Finally, Breeze provides you with a way to organize / access data from your thick client Web application. Whether you are using Angular, Backbone or Knockout, Breeze will help you manage your data in a way similar to ORM / ActiveRecord concepts.
So, all these components can easily work together, no doubts (sometimes people are talking about MEAN, MEANS, BMEAN stacks, where every letter is a first letter in the name of a framework / component). But ultimately, it's up to you to decide how many of them you should use in your product. As an example of approach, you can start with Mongo / Node base, and then choose necessary frameworks by asking yourself for the each one, whether it simplifies your life (especially, long-term-wise) or complicates it.
I'm currently developing a community (like a lightweight "social network") for a limited (local) target.
This is the first project where SEO doesn't matter and where I can happily exclude no-js users. That's why I'm thinking to start the project over and write my first site that is completely build with Javascript and my first Node application for educational reasons.
Details so far:
Browser: jQuery, maybe JavaScriptMVC (there are some things I don't like about JavaScriptMVC (like the routes), maybe I write my own little MVC or do you know a better suited framework?)
Server: Node.JS, Express framework, (maybe socket.io or nowjs for further features)
I got a few questions so far. I know it's better to ask a single question but there are more or less connected:
Express looks really nice but I'm missing MVC. I couldn't find any project that implements mvc and is build on Express. Is there a reason for that? Routing is nice in Express but I need a way to spread code across multiple files (controllers would be the best way I guess, the application won't be small and I need it maintainable)
The application will be more or less completely based on AJAX (json) requests. Is Express the right framework for such applications, anyway? I think the best way to write this project is to expose a json REST api which can then be queried by the web application over AJAX and by a mobile device app (which I'm also going to write). In my opinion Express' route system is quite suited for REST. But feel free to recommend other frameworks.
Have you seen Swagger? An API server available in Node.js with an automated UI Generator.
(source: wordnik.com)
To answer your primary question, yes there are controllers in Express. They are more akin to Sinatra (express is modeled after Sinatra rather than Rails). By that I mean they are light-weight method mappings to routes you define.
Browser: jQuery, maybe JavaScriptMVC (there are some things I don't
like about JavaScriptMVC (like the routes), maybe I write my own
little MVC or do you know a better suited framework?
I'd go with spine.js or backbone.js personally.
Express looks really nice but I'm missing MVC. I couldn't find any
project that implements mvc and is build on Express. Is there a reason
for that? Routing is nice in Express but I need a way to spread code
across multiple files (controllers would be the best way I guess, the
application won't be small and I need it maintainable)
You can spread files out all you want. I answered this here.
The application will be more or less completely based on AJAX (json)
requests. Is Express the right framework for such applications,
anyway? I think the best way to write this project is to expose a json
REST api which can then be queried by the web application over AJAX
and by a mobile device app (which I'm also going to write). In my
opinion Express' route system is quite suited for REST. But feel free
to recommend other frameworks.
I haven't built a 1 page app yet in node but from what I can tell, almost everyone seems to be using socket.io with backbone. That's not to say you can't, just that you'll find more examples that way.
You could check out Sails. Its structure is based on Rails.