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
So we've been using node for quite a while now and I must say, with the growing community for node, people are developing lots of awesome modules and frameworks too. But as we are working on more and more projects, I get confused sometimes as to which framework to go for. So far we've used following frameworks:
Express - One of my favorite frameworks for node and this was the first too when we started making apps in node.js.(I think this also was the first to gain so much popularity). We do have issues like callback hells but provided that the routing and the code organization is much more cleaner, we were pleased to use it.
KoaJS - Another one from the TJ and team, and this is just awesome! Using ECS 6 when any of the browsers hardly support them. (Specially when it helps you remove the callback hells completely). We had some issues with https compliance with Koa and had to re-write the entire server using hapi and also the fact that it depends on the unstable version on node for now.
Hapi - This is our most recent adoption and haven't done much with it, but the most fun part of this is the joi module that helps us validate requests(easily) even before they hit the actual server and also the automated docs generation.
Synth - I haven't interacted much with it, but while reading the docs, I came across
Use services and dependency injection just like AngularJS but on the
back-end!
which is awesome, but since it's in beta still, I'm not thinking of using it anytime soon.
So when trying to go for a framework for your app, Is there any specific set of features that one framework is good at and the others don't? Because honestly, we adopted most of the frameworks just with the intent of trying them out and apart from syntax differences (except Koa that uses ECS 6) and how they handle routes, I couldn't find much differences among them.
So my question is should we adopt any framework just by looking at it's popularity(which is what people generally do) or there is some checkpoints we need to consider while doing the same?
Any suggestions/help appreciated.
Edit
I wanted to add on that my intention for this question is to find out the key points to consider while opting for any of the node.js framework (rather than just depending on it's popularity or how many big names are using it). For the front-end we can easily tell because we already know or have been told the key features that would help development easier(the diff between angular & backbone can be an example) But for the node.js frameworks that isn't any way.
I would request others to consider my edits too.
I'll try and keep this answer as non-opinionated as possible. Please edit and help me improve this. This is a important topic and should get a good answer.
Express.js
Pros
Express.js is the big guy, fairly old and incredibly popular.
Easy to use views
Very Lightweight
Cons
No fancy features
Koa.js
Pros
Lightweight
Koa is the maybe successor to Express
No callback hell, thanks to ES6 generators
Built by the same guy as Express
Cons
Fairly new, not super refined
Uses ECMAScript 6 features, meaning you need Node.js v0.11 (unstable)
Hapi
Pros
Many official modules, but not a ton of third-party ones
Developed by a large corporation that uses it for their own products
Cons
Built by Walmart
Different syntax for specifying routes than Koa or Express.
Itself and all the official modules have weird names
Synth
The first back-end framework specially designed for single-page web applications.
Pros
Designed for being the backend single-page websites, ala Angular.js
API First
Dependency Injection, familiar to those coming from Java
Designed to do a ton of the backend things, allowing you to work on the frontend
Cons
Dependency Injection, disliked by quite a lot of people because Java is the only reason it exists
Very new, currently in beta
Doesn't work well with more traditional websites
More Resources
TechEmpower Framework Benchmarks (limit to Node.js) Benchmarks of lots of web frameworks, currently only has raw Node.js, Express, and Hapi for Node.js.
Related
I wanted to start a full stack project, with all the tech stacks in the market i am confused to which one should i pick. I know reactjs in frontend, nodejs and a little bit of django in backend.
First should i use Reactjs or any other frontend framework which is a single page application so all the JS code will execute from frontend or should i use that or Nextjs which does the server side rendering so in the browser we reduce the execution of js. If i stick with Nextjs then suppose i wanted to create a mobile app for my project can i use the nextjs for that or should i shift the code entirely
2)Does backend language really matter, if matters which language should i use and If it doesn’t matter then in nodejs which server framework should i pick(ex: expressjs)
Should I go with server or serverless while creating the api then it does not matter with the framework(because lately I have seen many realtime apps backend code is entirely wrriten by serverless functions using cloud)
4)tell me some of the important things i should use in a realtime app like docker, Kubernetes, load balancer, and any other things you might think this should be present in the full stack app
if you know any blogs or articles about choosing the architecture for ur project comment down.
This is a very opinion and experience based question that cannot be answered as you are asking it (and is technically out of scope in stackoverflow). I will try to help as much as possible anyway.
In general many different stacks are viable and in order to be productive it is more important that you are experienced in what you decide to use. This is because most technologies have pitfalls that can only be avoided by knowing them / experience.
Besides the frontend technologies/frameworks you listed there are many others. Having some experience with React-Native as well, my personal current favorites would be Angular and Flutter (both Google technologies) for web/apps.
It does and it doesn't matter. Without knowing your specific requirements no recommendation can be given though. As a general hint I recommend to use a language that your developers love - There is usually a reason for it. See the 2021 Stackoverflow Developer Survey.
Server vs. Serverless is mostly a business decision and you have to model your costs including hosting / development / maintenance efforts vs. usage models. Another aspect in this decision is time-to-market pressure since Serverless may be a bit faster to finish in some scenarios.
This cannot be answered without knowing the details and requirements of your project. Recommendations could be from hosting a static single web page in a S3 bucket to running your own fleet of (cloud-)-bare-metal clusters or buying a supercomputer.
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 6 years ago.
Improve this question
I'm caught in a fix. I've learned ExpressJS to develop a web app and I'm a quarter of my way done. Then comes along Meteor which was very recently released. It has gotten a lot of press, funding and it has the benefit of being able to port to Cordova. Now I'm not sure whether to stick to ExpressJS or transition to Meteor.
Key Points: Scalability, Ease of use, Development efficiency
Express = MVC Framework built in Javascript and is powered by Node.
Meteor = Full Stack that has the front-end and back-end components to build a real-time application.
To create the same implementation of Meteor using Express, you need to look at the MEAN stack, which includes MongoDB, Express, AngularJS, and Node. You can create the same thing in Meteor that you can with the MEAN stack, you are just going to be doing a lot more learning especially with AngularJS. Express and Angular are taken care of in Meteor using Meteor's template system and Blaze.
I would stick with Meteor. It still has a few drawbacks, but there are workarounds. It's amazing what you can throw together in little time.
You're comparing oranges with potatoes. Expressjs is backend and Meteor is fullstack, such a comparison is unfair at all!
I've been working with Meteor since 0.8 and I suffered in the skin the pain of upgrading, removing old vital third party packages, etc. you get the idea. Although Meteor reached 1.0, I don't think that the mobile component is quite ready, check github issues on it.
I think Meteor is ready for building online platforms. If you find that it doesn't play well in the mobile, you can still maintain your Meteor application and create an API on top of it, you can find packages on atmospherejs.com for it (or even use iron:router). That's what you would with Expressjs: create an API to be used by mobile devices.
About your Key Points of Meteor: Scalability - It's possible to scale Meteor although you won't a good article about it but if you take a look at Kadira, Arunoda managed to scale it. Ease of use - It's fairly easy to write a Meteor application in the beginning but in the long run you'll face some problems like I faced. Development efficiency - My experience in team wasn't that positive, we had bad architectural design choices and some bugs because new developers (even experienced ones) don't get Meteor, example: Instead of using Collections allow and deny rules, they use Meteor.methods for everything which doesn't translate to security. Some even publish the entire database to the client and say: Works great on my localhost :D
About express: I have little experience on it but the comparing it with Meteor, it's not fair at all. Meteor doesn't not the same purpose as Expressjs.
A comparison with MEAN Stack would make much more sense: http://mean.io/
Express.js is quite different from Meteor.
Meteor tries to give a good framework for everyone taking a lot of decisions (hopefully good decisions) those are usually uninteresting from the application development point of view: what transport library to use, how to synchronize data, how to build a reusable API, security, CRUD operations with the database, etc.
Instead Meteor gives you a unified experience across the stack. Since it has so much power control over backend, transport, interfaces, front-end, build tool chain - it can build a lot of neat features those would be so much harder to glue together from Mongo+Express+your favorite front-end framework+socket.io+grunt/gulp.
Read Socket.io's creator's blog on how hard it is to deliver good user experience in single-paged apps these days: http://rauchg.com/2014/7-principles-of-rich-web-applications/. Meteor does a lot of it +more. (except for the server-side rendering and predictions, at least right now).
Think about how many security holes you will have if you pick the abstractions too low level in hope to implement everything right.
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 4 years ago.
Improve this question
I am building a multiple page admin interface for an internal enterprise software platform. Think lots of glue logic tying together various APIs, db queries, and shell scripts.
We will be using node.js, the express framework (including jade templates), and LDAP for authentication.
I am struggling to find information regarding design patterns and best practices for authorization in node applications. Preferably, I would like to use the role-based model since my users are familiar with that approach and its care and feeding.
I am new to node.js so please don't assume I've already seen a module or popular blog post. It's probable that there's a wealth of information and I simply do not know where to look.
Thanks in advance for any information you are able to provide!
As per your first question, you want some authorization process implementation in NodeJs. I have explored and used number of APIs of NodeJs. I would prefer following APIs for enterprise applications.
For Authentication: Passport or Satellizer if developing SPA (front-end) in AngularJS.
For Authorization: ACL . Role based security on Methods and REST APIs. I would like to mention casbin if you want to use RABC, ABAC as well.
Second, you want some implementation and development approach in NodeJs.
Easy and my favourite design pattern and Framework for NodeJs: MVC framework , SailsJs . For its ready to start and modular architecture. Code management is easy in long run (Most practical requirement for an enterprise application). Easy maintenance. SailsJs is also preconfigured with Socket.io, using which you can create real time modules, widgets, chat widgets with in your project.
Express You can use Express and design your own custom MVC project structure. This is also popular and robust. You can find popular seed projects of the same on Yeoman
Redis As a caching or session layer. It is always good to use seperate caching or session layer, because it won't block you to scale your application on cloud to nth instances.
You can use Redis and Socket.io to create real-time features like Geo-location , user-presence(online/offline), chat, push-notification and many more.
ORM: Waterline . For its easy querying approach. It is also the inbuilt and default ORM of SailsJs. You can also use Sequelizejs, if not using SailsJs. I would recommend to use native connectors provided by DB providers.
Database: As per your requirement. Waterline ORM supports PostgreSQL, MySQL, MongoDB and more..
My faviourite view engine: EJS. No need to learn new things for developing your presentation layer. It is also the inbuilt and default view engine of SailsJs, that's why I am a fan of SailsJs.
I think, I have covered all important information to create an Enterprise application in NodeJs. I don't say, above packages are best, but collaboratively, they can be best fitted to any enterprise scenario. There are other known packages, which you can use according to your own requirement.
Here are some information to get started:
passport is a popular module for authentication
express auth example shows how do implement simple authentication without extra modules
express route middleware example explains how to implement role based authentication
blog post on nodejs.org about the ldapjs module
Hope that makes it easier to start.
Another option is to use CASL which is very good integrated with MongoDB. Also there is an article of how to itegrate authorization based on CASL into expressjs app - https://medium.com/#sergiy.stotskiy/authorization-with-casl-in-express-app-d94eb2e2b73b
I should say Node-Authorization is also a good candidate. The idea is borrowed from SAP(ERP provider), it is an object oriented authorization. And it can also be used as an accompaniment with other frameworks like: Passport and Express.
Closed. This question needs to be more focused. It is not currently accepting answers.
Closed 9 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
So I've been hearing/reading alot about meteor.js. The tutorials make it seem very sporty as a framework, but I'm still a bit of a novice when it comes to web programming.
I've been trying over the last month and half to really learn node.js and figure out how it all comes together. I like the how fast and easy it is to get up and running, and the community that comes along with it (which is exemplified by the mind blowing number of frameworks you can get for Node).
But what about meteor? What are the real advantages of it, and what's the difference? Has anyone started as a node.js user and 'converted' or is it still more of a curious new framework?
A loose analogy is, "Meteor is to Node as Rails is to Ruby." It's a large, opinionated framework that uses Node on the server. Node itself is just a low-level framework providing functions for sending and receiving HTTP requests and performing other I/O.
Meteor is radically ambitious: By default, every page it serves is actually a Handlebars template that's kept in sync with the server. Try the Leaderboard example: You create a template that simply says "List the names and scores," and every time any client changes a name or score, the page updates with the new data—not just for that client, but for everyone viewing the page.
Another difference: While Node itself is stable and widely used in production, Meteor is in a "preview" state. There are serious bugs, and certain things that don't fit with Meteor's data-centric conceptual model (such as animations) are very hard to do.
If you love playing with new technologies, give Meteor a spin. If you want a more traditional, stable web framework built on Node, take a look at Express.
Meteor is a framework built ontop of node.js. It uses node.js to deploy but has several differences.
The key being it uses its own packaging system instead of node's module based system. It makes it easy to make web applications using Node. Node can be used for a variety of things and on its own is terrible at serving up dynamic web content. Meteor's libraries make all of this easy.
Meteor's strength is in it's real-time updates feature which works well for some of the social applications you see nowadays where you see everyone's updates for what you're working on. These updates center around replicating subsets of a MongoDB collection underneath the covers as local mini-mongo (their client side MongoDB subset) database updates on your web browser (which causes multiple render events to be fired on your templates).
The latter part about multiple render updates is also the weakness. If you want your UI to control when the UI refreshes (e.g., classic jQuery AJAX pages where you load up the HTML and you control all the AJAX calls and UI updates), you'll be fighting this mechanism.
Meteor uses a nice stack of Node.js plugins (Handlebars.js, Spark.js, Bootstrap css, etc. but using it's own packaging mechanism instead of npm) underneath along w/ MongoDB for the storage layer that you don't have to think about. But sometimes you end up fighting it as well...e.g., if you want to customize the Bootstrap theme, it messes up the loading sequence of Bootstrap's responsive.css file so it no longer is responsive (but this will probably fix itself when Bootstrap 3.0 is released soon).
So like all "full stack frameworks", things work great as long as your app fits what's intended. Once you go beyond that scope and push the edge boundaries, you might end up fighting the framework...
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 9 years ago.
Improve this question
I see a lot of potential of doing Node.JS-like development on the JVM, with its heavily optimized runtime.
At this moment in time, I see three projects that aim to bring a node.js-like style of development to the JVM:
Apache Deft
Webbit
Vert.x (formerly Node.x)
Should these projects team up?
What are their relative strengths and weaknesses?
Which project has the most momentum?
Disclosure - I'm the vert.x guy :)
Vert.x is a fully fledged platform for building polyglot, scalable, asynchronous web-enabled applications.
It is heavily inspired from node.js but goes further than node.js and provides a distributed event bus which reaches from the server right into client side JavaScript thus creating a super simple model for so-called "real-time' web applications. We also ship with a mailer and a mongodb persistor. There's a full tutorial here http://vertx.io/tutorials.html
But the probably the main thing that sets it apart from other async frameworks is it's polyglot nature. The same (or similar) API is available in Java, Ruby, JavaScript and Groovy (with Clojure, Python and Scala support to follow).
Vert.x really takes advantage of true multi-threading on the JVM to provide scalability and performance than node.js cannot touch.
If you don't want the whole platform. Vert.x can also be used as a library for providing HTTP, TCP, websockets, sockjs, eventbus, etc support in your Java or Groovy application.
For more info pls see the website http://vertx.io
Disclaimer: I'm the Webbit guy
There is definitely a lot of overlap between the 3 projects. When I built Webbit I was not aware of the other two - had I been, it may well not exist, or I may have spent my time contributing to the others.
I can talk a bit about Webbit...
It is not a multi-purpose evented IO framework. Or network protocol toolkit. Or filesystem abstraction. Webbit only does a small fraction of what the others do.
Webbit is also not a full-featured web-framework. Like Node.JS or the Servlet API, it provides the core building blocks for building higher level frameworks, but leaves this to external projects (like Webbit-EasyRemote or Webbit-REST).
What Webbit focuses on is being a simple, embeddable, non-blocking, HTTP and WebSocket server.
Because it takes the 'do one thing and do it well' approach, it has also been designed to be used in conjunction with other libraries. It allows external java.util.concurrent.Executors to be passed in and avoids singleton thread contexts, making it particularly well suited for integrating with Actor style concurrency libraries such as Jetlang and HeySync.
Vert.x and Deft bring complete frameworks for out-of-the-box Node style development. Webbit is just a small tool that can help HTTP/WebSocket enabled your application. There is a need for both of these and it really depends on your needs (and personal style) as to which is more appropriate.
Disclaimer: I'm an Apache Deft committer.
Apache Deft has more in common with tornado and twisted than to node.js, whereas vert.x is heavily influenced by node.js. Tim Fox from wmware is doing a great job with vert.x and the development speed is really impressive.
vert.x has a couple of examples available.
Some Apache Deft examples.
Apache Deft also has a bigger "demo application" that should give you an idea of how you could use the framework for other things than http.
AFAIK webbit is currently aiming to be a "WebSocket and HTTP server".
If they should team up? Absolutely :)