What is NestJS and what are its top alternatives?
Top Alternatives to NestJS
It is a Node.js Framework which is highly focused on developer ergonomics, stability and confidence. ...
Feathers is a real-time, micro-service web framework for NodeJS that gives you control over your data via RESTful resources, sockets and flexible plug-ins. ...
Koa aims to be a smaller, more expressive, and more robust foundation for web applications and APIs. Through leveraging generators Koa allows you to ditch callbacks and greatly increase error-handling. Koa does not bundle any middleware. ...
A highly-extensible, open-source Node.js framework that enables you to create dynamic end-to-end REST APIs with little or no coding. Connect to multiple data sources, write business logic in Node.js, glue on top of your existing services and data, connect using JS, iOS & Android SDKs. ...
hapi is a simple to use configuration-centric framework with built-in support for input validation, caching, authentication, and other essential facilities for building web applications and services. ...
Express is a minimal and flexible node.js web application framework, providing a robust set of features for building single and multi-page, and hybrid web applications. ...
Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. ...
Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. ...
NestJS alternatives & related posts
- Laravel like25
- Easy to learn21
- Beautiful code19
- ORM Mapper10
- Service Providers6
- Easy to understand documentation2
- Fast development2
- Schema migrations1
- Ace command-line tool1
- Small community4
- Poor documentation1
- Choose any ORM7
- Datastore Agnostic7
- Flexible Plugins6
- Choose Socketio or Primus5
- Easy Rest4
- Isomorphic Services API4
- Open source4
- Easy to use with Graphql3
- Service-oriented architecture3
- Data-driven APIs3
- Uses express, will support other options soon3
- Advanced Composable Service Middleware called holds3
related FeathersJS posts
Recently I have been working on an open source stack to help people consolidate their personal health data in a single database so that AI and analytics apps can be run against it to find personalized treatments. We chose to go with a #containerized approach leveraging Docker #containers with a local development environment setup with Docker Compose and nginx for container routing. For the production environment we chose to pull code from GitHub and build/push images using Jenkins and using Kubernetes to deploy to Amazon EC2.
We also implemented a dashboard app to handle user authentication/authorization, as well as a custom SSO server that runs on Heroku which allows experts to easily visit more than one instance without having to login repeatedly. The #Backend was implemented using my favorite #Stack which consists of FeathersJS on top of Node.js and ExpressJS with PostgreSQL as the main database. The #Frontend was implemented using React, Redux.js, Semantic UI React and the FeathersJS client. Though testing was light on this project, we chose to use AVA as well as ESLint to keep the codebase clean and consistent.
Fontumi focuses on the development of telecommunications solutions. We have opted for technologies that allow agile development and great scalability.
Firebase and Node.js + FeathersJS are technologies that we have used on the server side. Vue.js is our main framework for clients.
Our latest products launched have been focused on the integration of AI systems for enriched conversations. Google Compute Engine , along with Dialogflow and Cloud Firestore have been important tools for this work.
Git + GitHub + Visual Studio Code is a killer stack.
- REST API1
related Koa posts
I think next step could be to use Koa but I am not sure.
- Need a nodejs ReST-API, DB, AAA, Swagger? Then loopback11
- Easy Database Migration9
- Code generator6
- The future of API's4
- Community is slow7
- Backward compatibility1
related LoopBack posts
We inherited this project and the backend is using LoopBack v3. I haven't taken a look at Loopback.io v4, but I'm planning to replace it. The reason being is that Loopback v3 documentation is a bit confusing and we are having trouble packaging the build using Webpack. Not to mention, integrating unit tests (latest Jest).
I still think Loopback is a great tool, but their documentation is really "messy" and hard to navigate through. There's also a constraint of time from our side. So what's the best option out there?
Should I try upgrading to Loopback v4, or trying other stuff? (i.e. NestJS)
I use LoopBack because it is: * It is truly and Unbelievably Extensible * it is default integrated with OpenAPI (Swagger) Spec Driven REST API * I write lesser codes, because most of the user stories have been covered using the code generation * It's documentation is more compact and well detailed than ExpressJS * It is very easy to learn, hence you can build a basic Rest API App in minutes * It has built in NPM packages required to build my Rest API which saves me time on installation and configuration * The Datasource/Service/Controller concept is just Brilliant (that's mostly all you need to get your app speaking with an External API services) * The support for SOAP and Rest API services is amazing!
- Makes me Hapi making REST APIs27
- Simpler than other REST libraries14
- Quality Driven Ecosystem13
- Easy testability5
- Better validation1
related hapi posts
What is the best way to increase your income as a freelancer in 2019? What frameworks should be the best to learn? React Node.js Docker Kubernetes Sequelize Mongoose MongoDB ExpressJS hapi Based on trends I've picked up a JS full stack. If you need to work under startups you may replace React with Vue.js . If you want to work in outsourcing Angular 2+ may be better.
What is your opinion?
- High performance192
- Robust routing150
- Open source70
- Great community57
- Hybrid web applications37
- Well documented13
- Sinatra inspired9
- Rapid development9
- Isomorphic js.. superfast and easy7
- Socket connection5
- Light weight5
- Resource available for learning4
- Event loop3
- Data stream2
- Not python27
- No multithreading14
- Not fast5
- Easily Insecure for Novices2
related ExpressJS posts
Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.
Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.
Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.
Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.
Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.
- Rapid development656
- Open source480
- Great community414
- Easy to learn369
- Beautiful code224
- Great packages196
- Great libraries185
- Comes with auth and crud admin panel72
- Great documentation69
- Great for web64
- Great orm39
- Great for api37
- All included28
- Web Apps23
- Used by top startups20
- Easy setup19
- Convention over configuration14
- Allows for very rapid development with great libraries13
- The Django community12
- King of backend world10
- Great MVC and templating engine9
- Full stack8
- Batteries included7
- Its elegant and practical7
- Have not found anything that it can't do6
- Very quick to get something up and running6
- Fast prototyping6
- Zero code burden to change databases5
- Easy to develop end to end AI Models5
- Easy Structure , useful inbuilt library5
- Great peformance4
- Python community4
- Many libraries4
- Easy to use4
- Easy to change database manager4
- Just the right level of abstraction3
- Full-Text Search3
- Node js1
- Underpowered templating25
- Autoreload restarts whole server22
- Underpowered ORM21
- URL dispatcher ignores HTTP method15
- Internal subcomponents coupling10
- Not nodejs8
- Configuration hell7
- Not as clean and nice documentation like Laravel5
- Bloated admin panel included3
- Not typed3
- InEffective Multithreading2
- Overwhelming folder structure2
related Django posts
Simple controls over complex technologies, as we put it, wouldn't be possible without neat UIs for our user areas including start page, dashboard, settings, and docs.
Initially, there was Django. Back in 2011, considering our Python-centric approach, that was the best choice. Later, we realized we needed to iterate on our website more quickly. And this led us to detaching Django from our front end. That was when we decided to build an SPA.
For building user interfaces, we're currently using React as it provided the fastest rendering back when we were building our toolkit. It’s worth mentioning Uploadcare is not a front-end-focused SPA: we aren’t running at high levels of complexity. If it were, we’d go with Ember.js.
However, there's a chance we will shift to the faster Preact, with its motto of using as little code as possible, and because it makes more use of browser APIs. One of our future tasks for our front end is to configure our Webpack bundler to split up the code for different site sections. For styles, we use PostCSS along with its plugins such as cssnano which minifies all the code.
All that allows us to provide a great user experience and quickly implement changes where they are needed with as little code as possible.
- Great libraries1.1K
- Open source802
- Great for apis485
- Great community420
- Great for realtime apps390
- Great for command line utilities296
- Node Modules82
- Uber Simple69
- Great modularity59
- Allows us to reuse code in the frontend58
- Easy to start42
- Great for Data Streaming35
- Non blocking IO25
- Can be used as a proxy18
- High performance, open source, scalable17
- Non-blocking and modular16
- Easy and Fun15
- Easy and powerful14
- Same lang as AngularJS13
- Future of BackEnd13
- Cross platform10
- Mean Stack8
- Great for webapps7
- Easy concurrency7
- Fast, simple code and async6
- Great speed5
- Easy to use and fast and goes well with JSONdb's5
- Its amazingly fast and scalable5
- Control everything5
- Fast development5
- Isomorphic coolness4
- Easy to use4
- It's fast4
- Great community3
- Scales, fast, simple, great community, npm, express3
- TypeScript Support3
- Sooper easy for the Backend connectivity3
- Not Python3
- One language, end-to-end3
- Easy to learn3
- Less boilerplate code3
- Performant and fast prototyping3
- Blazing fast3
- Event Driven2
- Npm i ape-updating2
- Creat for apis1
- Bound to a single CPU46
- New framework every day44
- Lots of terrible examples on the internet38
- Asynchronous programming is the worst31
- Dependency based on GitHub11
- Dependency hell11
- Low computational power10
- Very very Slow7
- Can block whole server easily7
- Callback functions may not fire on expected sequence6
- Unneeded over complication3
- Breaking updates3
- No standard approach2
- Bad transitive dependency management1
- Can't read server session1
related Node.js posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve: