|Hacker News, Reddit, Stack Overflow Stats|
No public GitHub repository stats available
|Why people like using this service||
|Companies using this service|
I'm using node modules through npm for this addon. Modules include babel, auto-changelog, and run-when-changed.
All backend servers at Wirkn are based on Node.js. Our production servers are always kept up to date with the latest LTS version.
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.
All backend projects I worked on during the past 3 years use Node at their core (mostly in combination with Express).
We use node.js to build backend services as well as middleware for our react-redux frontend applications.
Having a single language for the front-end and back-end could increase throughput and decrease our "containerization" of code ownership.
Plus, Node has some really exciting things happening in the tech space, and is one of the easiest ways to adopt best practices like micro-services and containerization.
NodeJS drove the app's backend server (ExpressJS), frontend build tools (Gulp and Webpack), linters (ESLint), and most of the database scripts (through Knex and Mongoose)
→ Lab9 Bot
Runs on Node v6+ as a standalone server. Optionally uses nodemon for monitoring of server process.
In order to speed up loading times and allow SEO, a separate node server runs along side the Django server to render React components serverside and return the rendered HTML.
Platform for the build and command line utilities, for client interface module.
It is not used directly
A lot of our tools that run on our IoT devices are written in Node.js. The simplicity & async nature of Node.js makes it very easy and efficient to develop and maintain these tools.
All my web applications and almost all of my command line scripts run on node.js
The framework the the http server to see the results and manage the documents processed.
Most of the code we write on the server-side is in Node, due to it's flexibility, ease of use and extremely quick runtime once setup correctly.
Natively async for network programming. Reach for Native Addons when you need extra horsepower.
We use Node for our full stack web framework. The native libraries provide unparalleled "isomorphic" functionality.
I use node.js mainly for backend-utility and data management scripts.
Node.js as an asynchronous allows easy scaling of our websocket server for the multiplayer aspect of the game
When ever there is a need for real time, event driven , non-blocking things this is my go to. It filles in the spots where Rails could not and it does that very well.
Rather than leverage Grunt.js, which is crap, repetitive tasks like minification can be done through Node.js scripts.
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.
Our web gateway is based on node-http-proxy, which allows us to have high performance and scalability.
Node.js is the base for the RESTful API and drives all background jobs on the Azure WebSites platform.
Node.js powers our new dashboard which is now super fast even while fetching 10-15 different data views.
We decided to move the provisioning process to an API-driven process, and had to decide among a few implementation languages:
We built prototypes in both languages, and decided on NodeJS:
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.
Wikipedia and other Wikimedia Foundation projects use Node.js for VisualEditor's backend, Parsoid.
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.
The social ranking platform, Klout, used to use a PHP & LAMP stack but found it difficult to continue to scale, so when they had the chance they moved to a Node.js backend. They even wrote about switching to Node.js and how they use it. [additional source: http://blog.klout.com/2011/10/the-tech-behind-klout-com/]
PRS UI app is built in Rails (originally a proof of concept which has now become the primary tool for interaction with the PRS API).
Rails 5 (beta 3) provided a nice structure for rendering responses, linking to front-end assets (compiled previously via Webpack), handling sessions w/ tailor made login links via an email button/token, background jobs, and creating an admin behind basic auth to allow managing of users and purchases.
Rails is used for some endpoints of our Frontend API. Though there are talks of deprecating it.
Rails is our product's backend app. It handles user registration/logging, product's logic and Inspector communication with our users' devices.
Rails makes it easy to build out sophisticated Web apps quickly, without re-inventing the wheel for each of our clients. SmartLogic ♥ Rails!
Using Rails as a go to thing for creating API's or full blown web apps. Love writing Ruby, convention over configuration style is great and it has a tons of gems and community behind it :)
Well-established framework for rapid development of web apps. Huge repository of good integrated 3rd party libraries (Gems)
The first live version of Leanstack was actually a WordPress site. There wasn’t a whole lot going on at first. We had static pages with static content that needed to be updated manually. Then came the concept of user-generated content and we made the switch to a full on Rails app in November of last year. Nick had a lot of experience with Rails so that made the decision pretty easy. But I had also played around with Rails previously and was comfortable working with it. I also knew I’d need to hire engineers with a lot more experience building web apps than I do, so I wanted to go with a language and framework other people would have experience with. Also, the sheer number of gems and tools available for Rails is pretty amazing (shout to RubyToolbox ).
I don’t see us ever having to move away from Rails really, but I could be wrong. Leanstack was built in Rails 3. For StackShare we decided to upgrade to Rails 4. Biggest issue with that has been caching. DHH decided to remove the standard page and action caching in favor of key-based caching (source)[http://edgeguides.rubyonrails.org/caching_with_rails.html#page-caching]. Probably a good thing from a framework-perspective. But pretty shitty to have to learn about that after testing out your new app and realizing nothing is cached anymore :( We’ll need to spend some more time implementing "Russian Doll Caching", but for now we’ve got a random mixture of fragment and action caching (usually one or the other) based on which pages are most popular.
We use Rails for webpages and projects, not for backend services. Actually if you click through our website, you won't notice it but you're clicking though, I think, seven or eight different Rails projects. We tie those all together with a front-end library that we wrote, which basically makes sure that you have a consistent experience over all these different Rails apps.
It's a gem, we call it Karmeleon. It's not a gem that we released. It's an internal gem. Basically what it does is it makes sure that we have a consistent layout across multiple Rails apps. Then we can share stuff like a menu bar or footer or that kind of stuff.
So if we start a new front end project it's always a Rails application. We pull in the Karmeleon gem with all our styling stuff and then basically the application is almost ready to be deployed. That would be an empty page, but you would still have top bar, footer, you have some custom components that you can immediately use. So it kind of bootstraps our entire project to be a front end project.
Web has always been in Rails from the beginning, so we used Redis for caching our items, which we had, from the beginning. Rails is kind of what we were comfortable with, and we knew we wanted the front end to be really, really snappy, so we de-normalized all the item attributes into Redis, and that's how it got served out.
The backend has always been in Rails from the beginning, so we used Redis for caching our items, which we had, from the beginning. Rails is kind of what we were comfortable with, and we knew we wanted the front end to be really, really snappy, so we de-normalized all the item attributes into Redis, and that's how it got served out.
Gardenbed installs all of the tools that are necessary to deploy a Ruby on Rails application to a VPS.
last time i used the android sdk was converting the tiktok app to ios. what a mess it was back then. the developer nature of the sdk was apparent vs apples offering.
Native android app with features such as event app, lead retrieval app, checkin app, session scanning, badge printing and ticket sales.
Uso del Android SDK para el desarrollo de aplicaciones para Android con geolocalización, multimedia y almacenamiento en la base de datos.
So we very, very early on, we were iOS only, then we thought, well we’re missing out on half of the market. We need to add Android. So we had a friend of ours start working on the Android app, and I had to build the API for him, but I was having a really hard time doing that because I didn’t know what he needed exactly, so I built the first version of the web store over the weekend because I wanted to have a client to consume myself for the API I was building.