Feed powered byStream Blue Logo Copy 5Created with Sketch.
Node.js

Node.js

Application and Data / Languages & Frameworks / Frameworks (Full Stack)

Decision at Stream about Go, Stream, Python, Yarn, Babel, Node.js, ES6, JavaScript, Languages, FrameworksFullStack

Avatar of nparsons08
Node.js Engineer & Evangelist at Stream ·
GoGo
StreamStream
PythonPython
YarnYarn
BabelBabel
Node.jsNode.js
ES6ES6
JavaScriptJavaScript
#Languages
#FrameworksFullStack

Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

#FrameworksFullStack #Languages

26 upvotes·1.4K views

Decision at Raygun about .NET, Node.js, FrameworksFullStack, Languages

Avatar of CmdrKeen
Co-founder & CEO at Raygun ·
.NET.NET
Node.jsNode.js
#FrameworksFullStack
#Languages

The core Web application of Raygun is still a Microsoft ASP.NET MVC application. Not too much has changed from a fundamental technology standpoint. We originally built using Mono, which just bled memory and would need to be constantly recycled. So we looked around at the options and what would be well suited to the highly transactional nature of our API. We settled on Node.js, feeling that the event loop model worked well given the lightweight workload of each message being processed. This served us well for several years.

When we started to look at .NET Core in early 2016, it became quite obvious that being able to asynchronously hand off to our queuing service greatly improved throughput. Unfortunately, at the time, Node.js didn’t provide an easy mechanism to do this, while .NET Core had great concurrency capabilities from day one. This meant that our servers spent less time blocking on the hand off, and could start processing the next inbound message. This was the core component of the performance improvement.

We chose .NET because it was a platform that our team was familiar with. Also we were skilled enough with it to know many performance tips and tricks to get the most from it. Due to this experience, it helped us get to market faster and deliver great performance.

#Languages #FrameworksFullStack

22 upvotes·503 views

Decision at Heap about Heap, Node.js, Kafka, PostgreSQL, Citus, FrameworksFullStack, Databases, MessageQueue

Avatar of drob
HeapHeap
Node.jsNode.js
KafkaKafka
PostgreSQLPostgreSQL
CitusCitus
#FrameworksFullStack
#Databases
#MessageQueue

Heap searched for an existing tool that would allow them to express the full range of analyses they needed, index the event definitions that made up the analyses, and was a mature, natively distributed system.

After coming up empty on this search, they decided to compromise on the “maturity” requirement and build their own distributed system around Citus and sharded PostgreSQL. It was at this point that they also introduced Kafka as a queueing layer between the Node.js application servers and Postgres.

If we could go back in time, we probably would have started using Kafka on day one. One of the biggest benefits in adopting Kafka has been the peace of mind that it brings. In an analytics infrastructure, it’s often possible to make data ingestion idempotent. In Heap’s case, that means that, if anything downstream from Kafka goes down, they won’t lose any data – it’s just going to take a bit longer to get to its destination. He’s also learned that you want the path between data hitting your servers and your initial persistence layer (in this case, Kafka) to be as short and simple as possible, since that is the surface area where a failure means you can lose customer data. We learned that it’s a very good fit for an analytics tool, since you can handle a huge number of incoming writes with relatively low latency. Kafka also gives you the ability to “replay” the data flow: “It’s like a commit log for your whole infrastructure #MessageQueue #Databases #FrameworksFullStack

14 upvotes·473 views

Decision at The New York Times about Kafka, Node.js, GraphQL, Apollo, React, PHP, MySQL, AngularJS

Avatar of nsrockwell
CTO at NY Times ·
KafkaKafka
Node.jsNode.js
GraphQLGraphQL
ApolloApollo
ReactReact
PHPPHP
MySQLMySQL
AngularJSAngularJS

When I joined NYT there was already broad dissatisfaction with the LAMP (AngularJS 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.

13 upvotes·1 comment·21.4K views

Decision at StackShare about Redis, CircleCI, Webpack, Amazon CloudFront, Amazon S3, GitHub, Heroku, Rails, Node.js, Apollo, Glamorous, React, Microservices, StackDecisionsLaunch, SSR, FrontEndRepoSplit

Avatar of ruswerner
Lead Engineer at StackShare ·
RedisRedis
CircleCICircleCI
WebpackWebpack
Amazon CloudFrontAmazon CloudFront
Amazon S3Amazon S3
GitHubGitHub
HerokuHeroku
RailsRails
Node.jsNode.js
ApolloApollo
GlamorousGlamorous
ReactReact
#Microservices
#StackDecisionsLaunch
#SSR
#FrontEndRepoSplit

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

8 upvotes·4.7K views

Decision at Kokoen GmbH about ExpressJS, Node.js, JavaScript, MongoDB, Go, MySQL, Laravel, PHP

Avatar of ASkenny
CEO at Kokoen GmbH ·
ExpressJSExpressJS
Node.jsNode.js
JavaScriptJavaScript
MongoDBMongoDB
GoGo
MySQLMySQL
LaravelLaravel
PHPPHP

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.

We also decided to switch the website from PHP and Laravel to JavaScript and Node.js and ExpressJS since working with the JSON Data that we were saving now in the Database would be easier.

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

8 upvotes·3K views

Decision at Uploadcare about Netlify, Gatsby, React, Node.js, Django, StaticWebHosting, StaticSiteGenerators, Frontend

Avatar of Zmoki
Frontend Team Lead at Uploadcare ·
NetlifyNetlify
GatsbyGatsby
ReactReact
Node.jsNode.js
DjangoDjango
#StaticWebHosting
#StaticSiteGenerators
#Frontend

Since 2011 our frontend was in Django monolith. However, in 2016 we decide to separate #Frontend from Django for independent development and created the custom isomorphic app based on Node.js and React. Now we realized that not need all abilities of the server, and it is sufficient to generate a static site. Gatsby is suitable for our purposes. We can generate HTML from markdown and React views very simply. So, we are updating our frontend to Gatsby now, and maybe we will use Netlify for deployment soon. This will speed up the delivery of new features to production.

#StaticSiteGenerators #StaticWebHosting

7 upvotes·2.2K views

Decision at Loanlink Gmbh about HTML5, Vue.js, Google Drive, MailChimp, Zapier, Trello, GitHub, React, Node.js, .NET, AngularJS, Rails

Avatar of bananatron
Product Engineer at Loanlink.de ·
HTML5HTML5
Vue.jsVue.js
Google DriveGoogle Drive
MailChimpMailChimp
ZapierZapier
TrelloTrello
GitHubGitHub
ReactReact
Node.jsNode.js
.NET.NET
AngularJSAngularJS
RailsRails

When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.

The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.

We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.

We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.

6 upvotes·11.6K views

Decision about PHP, .NET, JavaScript, Node.js

Avatar of Sparker73
Frontend Developer ·
PHPPHP
.NET.NET
JavaScriptJavaScript
Node.jsNode.js

Node.js is my choice because it uses very few resources to run and it is capable to handle tons of connections simultaneously. Most developers already know JavaScript, the evolution of ECMAScript is immediately reflected to Node.js and all you have to do is update your Server's Node.js version without time and effort. Thousands of improvements that makes it very powerful especially in asynchronous programming. The web is full of courses, dev communities, free sample code, plunkers and many knowledge sources on Node.js that facilitates the learning curve. What else we can ask from a legendary language that is still evolving? I am learning Node.js by developing a simple REST WebAPI and using it as a playground to test situations in which the main objective is to challenge Node.js and compare results and performance with .NET implementations and certain well known fast PHP implementations. Until now the results are astonishing. Summarizing: Node.js for backend is so far (in my opinion) the most recommended solution to get positive achievements in size, speed, power, concurrency, scalability, deployment and running costs.

5 upvotes·2.6K views

Decision about PagerDuty, Slack, Go, PHP, Java, Python, Ruby, Node.js, Sqreen

Avatar of paulblei
PagerDutyPagerDuty
SlackSlack
GoGo
PHPPHP
JavaJava
PythonPython
RubyRuby
Node.jsNode.js
SqreenSqreen

I chose Sqreen because it provides an out-of-the-box Security as a Service solution to protect my customer data. I get full visibility over my application security in real-time and I reduce my risk against the most common threats. My customers are happy and I don't need to spend any engineering resources or time on this. We're only alerted when our attention is required and the data that is provided helps engineering teams easily remediate vulnerabilities. The platform grows with us and will allow us to have all the right tools in place when our first security engineer joins the company. Advanced security protections against business logic threats can then be implemented.

Installation was super easy on my Node.js and Ruby apps. But Sqreen also supports Python , Java , PHP and soon Go .

It integrates well with the tools I'm using every day Slack , PagerDuty and more.

4 upvotes·4.2K views