Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I would like to use Node.js to develop a website. I've seen a lot of frameworks here: https://github.com/joyent/node/wiki/modules#web-frameworks-micro but do not know which one is the most accepted by the community (let's say: the most popular). Did anyone tried any of these frameworks and/or used it in production and what is your experience? Thanks.
Express.js seems to very popular to use as a general framework. Combined with socketio.js and underscore.js these are very popular libraries but they are not MVC.
For MVC I've only used backbone.js / spine.js and can't give any recommendation for the others. I don't think there is a framework with a dominating popularity going yet because node.js doesn't have much use in production.
There are statistics for popular downloads with npm somewhere. See if you can find them.
Another great MVC framework that is up and coming is Sails.JS. It is inspired by ruby on rails and has features such as socket support, Restful API and more.
http://www.sailsjs.com/
Try RailwayJS. CompoundJS
RailwayJS seems to have been killed and replaced with CompoundJS.
There's a guide for anyone that started with Railway and wants to migrate to Compound.
I just released Locomotive, which is an MVC framework inspired by Ruby on Rails.
Express is phenomenal, especially for smaller apps. Recognizing that, Locomotive is built completely on top of Express (similar to how Express builds on top of Connect). Locomotive essentially adds a controller layer along with a router that can declare resourceful routes and generates routing helper functions. Internally, everything is powered by Express, which means the view layer remains the same and all middleware can be reused.
One of the bigger hurdles when learning Node is figuring out how to best structure a web application. Locomotive attempts to solve that problem, using conventions from Ruby on Rails, while retaining the full power of Express and Node.
There is matador. It is MVC and it consists of many different existing components, such as Klass for inheritance model, express, hogan.js, and valentine. Backbone.js is pretty much used for client side. For node, i think there's probably only matador that I know.
I'd suggest you against using it if you're to use matador for production or replace your existing MVC platform (or at least have a bottleneck/good reason to use it) since it's pretty new, and your productivity also depends on the javascript resources you have. We ourselves use node.js very extensively (our node.js deployment serves close to +4 Million users to date) and we have a significant number of javascript specialists here..so we experiment a lot and probably look into using matador soon. Hope that helps.
Geddy was the original MVC framework for Nodejs, check out http://geddyjs.org if you're interested.
Just came across a new one called Derby which looks like it has a lot of promise. Its main benefit seems to be that it cuts down on a lot of the "glue code" (as they put it) that we often write when trying to use rails and backbone, or django and backbone together. The documentation seems pretty decent for a node framework as well.
Monorail.js - Ultra lightweight MVC Framework for Node.js
https://github.com/runexec/Monorail.js
There are a few more frameworks which you could check:
ThinkJS https://thinkjs.org/ the first Node.js MVC framework that can use full ES6/7 features to develop Node.js application.
Feathers http://feathersjs.com/ a minimalist real-time framework.
Meteor https://www.meteor.com/
Keystone.js http://keystonejs.com/ built on Express and MongoDB (MIT license).
seneca.js http://senecajs.org/ Everything external to a business logic - such as databases, caches and third-party integrations - is hidden behind microservices.
Catberry http://catberry.org/ was developed to help create apps that use the same codebase on both the server and client environments to render what the client would see as a "Single Page Application".
Nuke.js http://nukejs.com/#/ Fast framework. The stack contains primus, express, mithril, mongodb and redis
Hapi.js http://hapijs.com/ rich web application server framework for Node.js.
total.js https://www.totaljs.com/ The framework contains full web server, view engine, SMTP mail sender, localization, image processing, websockets, isomorphic code and a lot of utilities
Related
I'm building a new Laravel 8 application and given the reactivity features available with Livewire package, that essentially turn a backend developer into a full-stack developer (no advanced Javascript knowledge needed), I don't use any POST actions or request handling logic in my scripts. Every CRUD operation is handled with modal windows and AJAX requests. So my question is: Are there some drawbacks in this approach? Are there some limitation that will emerge in the future from the fact that my scripts don't directly handle HTTP request?
Thanks for your opinions.
FYI I'm not familiar with Laravel or Livewire. I'll use the term "platform" below as a general word to encapsulate technologies and libraries, etc, such as what you describe.
Platforms tend to focus on the high-value scenarios that most people need - so as long as what you need the platform to do aligns with what it can do, you're fine (e.g. simple CRUD). But, if you need to do something that pushes the boundaries of what the platform can do then you'll run into issues: it may not be possible; it's possible but really inefficient / a pig to work on; distorts your architecture and decision making.
Platforms like this are good in that they hide complexity, which is great until you need to access it and look under the hood. This applies to everything from debugging to developing features using approaches that the platform / platform designers haven't allowed for.
As a new developer, learning how to do things "the long way" (e.g. hand-code AJAX calls) is great as a learning experience. By doing that you can better appreciate how platforms like the ones you mention work - because you understand the underlying principles. So, a disadvantage is that new developers won't get that experience through working on this solution - they'll have to do that as a side project (which is not "evil", but it is a consideration).
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 apologize if this question is too open ended. But I am struggling to get some of the principles to get started diving into this.
I am planning to build a fairly small demo app out of this seed (based on Angular 2): https://vmware.github.io/clarity/get-started
I'd like to render in an Angular UI some basic data that I keep in a back-end Redis database.
I am trying to find out what application layer I should be using to sit in between Redis and the Angular UI.
I am currently thinking of either using Ruby (just because I am slightly familiar with it) or Node.js.
Part of my struggling is because I am confused about the relation between Node.js and Angular 2 and I am wondering whether using Node code can help me integrating better and more easily with Angular (than with Ruby).
Other than using the same language/syntax (js), I have the gut feeling that I could more easily run a Node "app.js" file with some trivial business logic that reads from Redis and pass the result onto the Angular application. At least I could run the app.js logic on the same http instance where I am running the Angular application (my assumption).
If I wanted to use Ruby I have to use some web framework (e.g. Rails or Sinatra) to serve requests coming from the Angular application (e.g. in Angular I will have to make calls to http://myrubysrv/applogic).
Other than the language and this deployment detail, I am just wondering if passing variable from the application logic component into the Angular application is going to be easier if I use Node or the level of effort is going to be exactly the same whether I use Node or Ruby.
Thanks.
You do have some options here. Angular 2+ apps compile to what is essentially just an index.html that will handle the loading of other necessary views. So, you just need something that is able to serve an index.html file, and your application API could live completely separate from your serving application. Depending on how you're hosting, you have a lot of options here (for example, GitHub pages hosting your frontend and your backend on Heroku.
Rails makes setting up an API-only application a breeze and works quite well with Redis. I would say it's definitely the easiest option here; if you do need to pass in environment-specific configs to the Angular app, there are ways to do this while bootstrapping the startup.
Node is always a good option, but I've never worked with Node-Redis so I couldn't tell you the hangups. I can also say that Rails would likely be easier.
However, Angular Universal primarily supports Node, with the only other supported platform being .NET. If you want to use or mess with Universal (super cool stuff) Node would be needed, at least when serving the app.
Node would also offer a chance to brush up on your Typescript chops outside of Angular, if you are looking for a learning opportunity.
Angular is agnostic to the backend you use. Just expose a REST endpoint either from your RUby or Node+Expres backend. The client will use something like this anyway:
http.get("/products").subscribe(...)
Take a look at these code samples where Angular talks to Node:
https://github.com/Farata/angular2typescript/tree/master/Angular4/http-node-samples
To start with, please be sorry, I just start developping applications on AWS and I have some question that could be easy for you but not really for me... But impossible to find any response about web integration of a java website on SWF...
I'm also a new user of the spring framework, I need to do some tutorials about it (or not? SWF documentation can be enough?). But my questions are for those who have already passed time on it and can say what is the best aproach in my case. (And why?)
What is the good approach in UI design to have a web based application with ui dynamic changes? (like content slide, menu, etc... the most scalable choice)
Having the view (GWT web interface running on Elastic Beanstalk for example, or a CloudFront PHP interface using a good MVC PHP Framework?) separated from the model running on SWF? All linked by the API's.
Or having my complete web application using Flow FrameWork and GWT? (or another technology? For now I chosed this even if I have to work tutorials too, but why not using the new Dart Google's solution?)
What is the easiest approach to do it efficiently?
I understood the SWF logical approach, and I have all my project's architecture (so the scalable SWF Model) in my head, but clearly, if I want to add a new service in my project and if this service wants to get a list of existing objects (stocked in DynamoDB for example), i'd like to show this information easily because I already did it for this object.
And so, with a copy of the model on the PHP interface, I imagine I could associate methods to show this object, and so concentrate the PHP projet for showing my objects and start workflows with PHP (search and read-only?), and SWF to have a good working model launching those WF. Is it a good approach? Is there a PHP framework really adapted to do this? Rather, I do it on a non-swf java UI application?
Finally I found what I was searching about. To connect an UI interface, we have just to use good classes of the SDKs :
http://docs.amazonwebservices.com/AWSSDKforPHP/latest/index.html#i=AmazonSWF
http://docs.amazonwebservices.com/AWSJavaSDK/latest/javadoc/index.html
My question was really simple, but I wasn't able to understand the entire SWF architecture.
So the solution is to implement the application's MODEL-CONTROLER with the SWF Flow FrameWork, and after that, we can connect the VIEWs with any of the SDK to start workflows. We can also connect an Android or iPhone application easily with the good SDK.
There are number of REST frameworks around for ASP.NET MVC. Which one is the most mature in your opinion? Following are few I briefly looked at, but I couldn't decide.
Snooze
BistroMVC
Restful Service with WCF
OpenRasta
Siesta
REST support build in ASP.Net MVC SDK
.... there are few more.
Personally I would go with the default ASP.NET routing engine which is built and supported by Microsoft. This will ensure that you won't find yourself one day into the position of having to migrate some code which has become obsolete because the authors simply decided to abandon the project. Of course if there is something specific that you want to implement which isn't supported out of the box you could search for alternatives. But as far as exposing a RESTful API is concerned the routing engine should work just fine.
I completely agree with Darin.
But if you're looking for something closer to what WCF offers (Web service, versus a typical Web site), I've been extremely happy with WCF REST.
There's a WCF REST Service Template available via Visual Studio's Extension Manager that will get you up and running fairly quickly.
OpenRasta
Have been implementing RESTFul service using OR, only one word to describe it => "Pure Awesomeness" ....actually it's 2 words.
For me the simplicity is a plus, the framework is easy to use and adopt to. Some of it's conventions in my opinion really help me to understand Resful. Many integration points in the framework, very easy to extend its functionalists.
watching video recordings of seb's talk is very entertaining as well :) very opinionated (in a good way IMO)
I agree with Darin. Personally, I think Apache Thrift is also an option for doing client and server communication.
I've been reading through a couple of questions on here and various articles on MVC and can see how it can even be applied to GUI event intensive applications like a paint app.
Can anyone cite a situation where MVC might be a bad thing and its use ill-advised?
EDIT: I'm specifically talking about GUI applications here!
I tried MVC in my network kernel driver. The patch was rejected.
I think you're looking at it kind of backwards. The point is not to see where you can apply a pattern like MVC, the point is to learn the patterns and recognize when the problem you are trying to solve can naturally be solved by applying the pattern. So if your problem space can be naturally divided into model, view and controller then it is a good candidate for MVC. If you can't easily see which parts of your design fall into the three categories, it may not be the appropriate pattern.
MVC makes sense for web applications.
In web applications, you process some data (on SA: writing questions, adding comments, changing user info), you have state (logged in user), you don't have many different pages, but a lot of different content to fit into those pages. One Question page vs. a million questions.
For making CMS, for example, MVC is useless. You don't have any models, no controllers, just a pages of text with decorations and menus. The problem is no longer processing data - the problem now is serving that text content properly.
Tho, CMS Admin would build on top of MVC just fine, it's just user part that wouldn't.
For web services, you'd better use REST which, I believe, is a distinct paradigm.
WebDAV application wouldn't benefit greatly from MVC, either.
The caveat on Ruby for Web programming is that Rails is better suited for building Web applications. I’ve seen many projects attempt to create a WebDAV server or a content management system CMS with Rails and fail miserably. While you can do a CMS in Rails, there are much more efficient technologies for the task, such as Drupal and Django. In fact, I’d say if you’re looking at a Java Portal development effort, you should evaluate Drupal and Django for the task instead.
Anything where you want to drop in 3rd party components will make it tough to work in the MVC pattern. A good example of this is a CMS.
Each component you get will have their "own" controller objects and you won't be able to share "control" of model -> ui passing.
I don't necessarily know that MVC is ever really a bad idea for a GUI app. But there are alternatives that are arguably better (and also arguably worse depending on whose opinion you're asking). The most common is MVP. See here for an explanation: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask.
Although I suppose it might be a bad idea to use MVC if you're using a framework or otherwise interacting with software that wasn't designed with MVC in mind.
In other words, it's a lot like comparing programming languages. There's usually not many tasks that one can say that one is better than the other for. It usually boils down to programmer preference, availability of libraries, and the team's experience.
MVC shouldn't be used in applications where performance is critical. I don't know if this still applys with the increase of computing power but one example is a call center application. If you can save .5 seconds per call entering and updating information those savings add up over time. To get the last bit of performance out of your app you should use a desktop app instead of a web app and have it talk directly to the database.
When is it a bad thing? Where ever there is another code-structure that would better fit your project.
There's countless projects where MVC wouldn't "fit", but I don't see how a list of them would be of any benefit..
If MVC fits, use it, if not, use something else..
MVC and ORM are a joke....they are only appropriate when your app is not a database app, or when you want to keep the app database agnostic. If you're using an RDBMS that supports stored procedures, then that's the only way to go. Stored procs are the preferred approach for experienced application developers. MVC and ORM are only promoted by companies trying to sell products or services related to those technologies (e.g. Microsoft trying to sell VS). Stop wasting your time learning Java and C#, focus instead on what really matters, Javascript and SQL.