Node.js is an open source tool with 35.5K GitHub stars and 7.78K GitHub forks. Here's a link to Node.js's open source repository on GitHub.
What is Node.js?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Back at the start of 2017, we decided to create a web-based tool for the SEO OnPage analysis of our clients' websites. We had over 2.000 websites to analyze, so we had to perform thousands of requests to get every single page from those websites, process the information and save the big amounts of data somewhere.
Very soon we realized that the initial chosen script language and database, PHP, Laravel and MySQL, was not going to be able to cope efficiently with such a task.
By that time, we were doing some experiments for other projects with a language we had recently get to know, Go , so we decided to get a try and code the crawler using it. It was fantastic, we could process much more data with way less CPU power and in less time. By using the concurrency abilites that the language has to offers, we could also do more Http requests in less time.
Unfortunately, I have no comparison numbers to show about the performance differences between Go and PHP since the difference was so clear from the beginning and that we didn't feel the need to do further comparison tests nor document it. We just switched fully to Go.
There was still a problem: despite the big amount of Data we were generating, MySQL was performing very well, but as we were adding more and more features to the software and with those features more and more different type of data to save, it was a nightmare for the database architects to structure everything correctly on the database, so it was clear what we had to do next: switch to a NoSQL database. So we switched to MongoDB, and it was also fantastic: we were expending almost zero time in thinking how to structure the Database and the performance also seemed to be better, but again, I have no comparison numbers to show due to the lack of time.
As of now, we don't only use the tool intern but we also opened it for everyone to use for free: https://tool-seo.com
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:
I think next step could be to use Koa but I am not sure.
For many(if not all) small and medium size business time and cost matter a lot.
That's why languages, frameworks, tools, and services that are easy to use and provide 0 to productive in less time, it's best.
Maybe Node.js frameworks might provide better features compared to Rails but in terms of MVPs, for us Rails is the leading alternative.
Amazon EC2 might be cheaper and more customizable than Heroku but in the initial terms of a project, you need to complete configurationos and deploy early.
Advanced configurations can be done down the road, when the project is running and making money, not before.
Finally, comunication and keeping a good history of conversations, decisions, and discussions is important so we use a mix of Slack and Twist
When building Checkly, I found it pretty hard to find good, solid examples on how to implement this. Specifically for my stack of Vue.js and Node.js / hapi
Turns out this is a mix of things:
- Feature toggling
- Counting stuff™
- Custom API middleware very specific to your situation
Read my post on how we did this and where the bottlenecks are. The HackerNews thread on this has some great contributions too.
Two weeks ago we released the public API for Checkly. We already had an API that was serving our frontend Vue.js app. We decided to create an new set of API endpoints and not reuse the already existing one. The blog post linked below details what parts we needed to refactor, what parts we added and how we handled generating API documentation. More specifically, the post dives into:
- Refactoring the existing Hapi.js based API
- API key based authentication
- Refactoring models with Objection.js
- Validating plan limits
- Generating Swagger & Slate based documentation
Possible pros for Python / Django: - easy syntax, easier to learn for me as a beginner - fast development, earlier release - libraries for mathematical and scientific computation
Which software would you use in my case? Are my arguments for Python/NodeJS right? Which kind of database would you use?
Thank you for your answer!
I'm planning to create a web application and also a mobile application to provide a very good shopping experience to the end customers. Shortly, my application will be aggregate the product details from difference sources and giving a clear picture to the user that when and where to buy that product with best in Quality and cost.
I have planned to develop this in many milestones for adding N number of features and I have picked my first part to complete the core part (aggregate the product details from different sources).
As per my work experience and knowledge, I have chosen the followings stacks to this mission.
Service: I have planned to use Java as the main business layer language as I have 7+ years of experience on this I believe I can do better work using Java than other languages. In addition, I'm thinking to use the stacks Node.js.
Database and ORM: I'm gonna pick MySQL as DB and Hibernate as ORM since I have a piece of good knowledge and also work experience on this combination.
Search Engine: I need to deal with a large amount of product data and it's in-detailed info to provide enough details to end user at the same time I need to focus on the performance area too. so I have decided to use Solr as a search engine for product search and suggestions. In addition, I'm thinking to replace Solr by Elasticsearch once explored/reviewed enough about Elasticsearch.
Host: As of now, my plan to complete the application with decent features first and deploy it in a free hosting environment like Docker and Heroku and then once it is stable then I have planned to use the AWS products Amazon S3, EC2, Amazon RDS and Amazon Route 53. I'm not sure about Microsoft Azure that what is the specialty in it than Heroku and Amazon EC2 Container Service. Anyhow, I will do explore these once again and pick the best suite one for my requirement once I reached this level.
Build and Repositories: I have decided to choose Apache Maven and Git as these are my favorites and also so popular on respectively build and repositories.
Additional Utilities :) - I would like to choose Codacy for code review as their Startup plan will be very helpful to this application. I'm already experienced with Google CheckStyle and SonarQube even I'm looking something on Codacy.
Happy Coding! Suggestions are welcome! :)
With Nodes' robust ecosystem of packages via npm and the team behind it having L.T.S. releases, you can safely trust using Node for enterprise-tier, in-production applications to support rapidly evolving businesses and their ever-changing needs.
MAJOR item of note is due to the large ecosystem of package available, having a solid vetting and review system when looking to use/import public packages is a must to maintain application security.
MAJOR item of note is due to the large ecosystem of packages available having an automated process for managing dependencies across a project and project's dev Dependancies is critical for application security (and developer sanity) but should not be the only line of defence.
Devils' Advocate Of course, this sunshine and rainbows above come at the cost of upkeep, some added development complexity, good documentation behaviour (not just code comments...) and real on-boarding for the Jr's. As with all decisions in a DevOps pipeline looking to do this, it should not be implemented without good team planning.
The power of SSR React and then hydrating it client-side to add interactivity and App-like feel is what makes Gatsby powerful.
It comes with a ton of plugins, that are mind-boggling: Image Processing, GraphQL, Node.js, and so much more. This is thanks to a great ecosystem, a great user-base and the revolutionary Community work, which led to the Gatsby repo to be one of the most committed to, out there.
We recently went through building and setting up free SSL for custom domains for our #SaaS customers. This feature is used for hosting public status pages and dashboards under the customers' own domain name.
We are in the #Node.js, #AWS and #Heroku world, but most of the things we learned are applicable to other stacks too.
The post linked goes into three things:
- Configuring the Let's Encrypt / ACME client called Greenlock.
- Getting DNS right on Amazon Route 53
- Actually determining what content to serve based on hostname.
All seem pretty straightforward, but there are gotcha's at each step.
Hope this helps other budding SaaS operators or ops peeps that need this functionality.
My SaaS recently switched to Intercom for all customer support and communication. To get the most out of Intercom, you need to integrate it with your app. This means instrumenting some code and tweaking some bits of your app's navigation. Checkly is a 100% Vue.js app, so in this post we'll look at the following:
- Identifying a user with some handy attributes
- Getting page views right with Vue Router
- Sending events with Vuex
- Some nice things you can now do in Intercom
After finishing this integration, you can actively segment your customers into trial, lapsed, active etc. etc.
I have benchmarked Node.js and other popular frameworks using a real life application example. You can find the results here: https://firstname.lastname@example.org/web-rest-api-benchmark-on-a-real-life-application-ebb743a5d7a3
- Most server-side scripts, all unit tests, all build tools, etc. were driven by NodeJS.
- ExpressJS served as the 'backend' server framework.
- MongoDB (which stores essential JSON) was the main database.
- MongooseJS was used as the main ORM for communicating with the database, with KnexJS used for certain edge cases.
- MochaJS, ChaiJS, and ExpectJS were used for unit testing.
- Frontend builds were done with Gulp and Webpack.
- Package management was done primarily with npm - with a few exceptions that required the use of Bower (also configured with JSON).
- The frontend was build primarily with ReactJS (as the View) and Redux (as the Controller / Store / frontend model).
- Configuration was done with json files.
The only notable exceptions were the use of SCSS (augmented by Compass) for styling, Bash for a few basic 'system chores' and CLI utilities required for development of the app (most notably git and heroku's CLI interface), and a bit of custom SQL for locations where the ORM extractions leaked (the app is DB-agnostic, but a bit of SQL was required to fill gaps in the ORMs when interfacing with Postgres).
We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:
- Go, the server-side language from Google
We built prototypes in both languages, and decided on NodeJS:
- NodeJS is asynchronous-by-default, which suited the problem domain. Provisioning is more like “start the job, let me know when you’re done” than a traditional C-style program that’s CPU-bound and needs low-level efficiency.
- NodeJS acts as an HTTP-based service, so exposing the API was trivial
Getting into the headspace and internalizing the assumptions of a tool helps pick the right one. NodeJS assumes services will be non-blocking/event-driven and HTTP-accessible, which snapped into our scenario perfectly. The new NodeJS architecture resulted in a staggering 95% reduction in processing time: requests went from 7.5 seconds to under a second.
The server side of Trello is built in Node.js. We knew we wanted instant propagation of updates, which meant that we needed to be able to hold a lot of open connections, so an event-driven, non-blocking server seemed like a good choice. Node also turned out to be an amazing prototyping tool for a single-page app. The prototype version of the Trello server was really just a library of functions that operated on arrays of Models in the memory of a single Node.js process, and the client simply invoked those functions through a very thin wrapper over a WebSocket. This was a very fast way for us to get started trying things out with Trello and making sure that the design was headed in the right direction. We used the prototype version to manage the development of Trello and other internal projects at Fog Creek.
All backend code is done in node.js
We have a SOA for our systems. It isn't quite Microservices jsut yet, but it does provide domain encapsulation for our systems allowing the leaderboards to fail without affecting the login or education content.
We've written a few internal modules including a very simple api framework.
I don't know how well this will scale if/when I have hundreds of people connected simultaneously, but I suspect that when that time comes, it may be just a matter of increasing the hardware.
Used node.js server as backend. Interacts with MongoDB using MongoSkin package which is a wrapper for the MongoDB node.js driver. It uses express for routing and cors package for enabling cors and eyes package for enhancing readability of logs. Also I use nodemon which takes away the effort to restart the server after making changes.
We are now re-considering TypeScript because 1) the tooling has improved significantly, and 2) and the root cause of the majority of our front-end bugs are related to typing (despite having PropTypes).