 Your new post is loading...
Your new post is loading...
Scoop.it!
In this video recorded on Feb 3, 2015 at the BayNode Meetup in Mountain View, Shubhra Kar from StrongLoop walks through a compare and contrast of various Node frameworks like Express, Hapi, restify, sail.js, Meteor and LoopBack and their suitability for building scalable APIs. 
No comment yet.
Sign up to comment
Scoop.it!
MassiveJS is a dedicated data access tool for Postgres and NodeJS Massive's goal is to help you get data from your database. This is not an ORM, it's a bit more than a query tool - our goal is to do just enough, then get out of your way. I'm a huge fan of Postgres and the inspired, creative way you can use it's modern SQL functionality to work with your data. ORMs abstract this away, and it's silly. Postgres is an amazing database with a rich ability to act as a document storage engine (using jsonb) as well as a cracking relational engine. Massive embraces SQL completely, and helps you out when you don't feel like writing another mundane select * from statement.
Matloob Hasan's curator insight,
March 21, 2015 1:06 AM
I have used Postgres on Node.js with Sequelize. I liked Postgres when I first read about it, loved it with Sequelize. But MassiveJs takes it to a whole new level!
Scoop.it!
From
scotch
Reapp was recently released on React. It’s a mobile app platform designed for performance and productivity. Think of it as a well-optimized UI kit, along with a build system and a bunch of helpers that let you build apps easily. To explore using Reapp we’re going to build an app that lets you search with the Flickr API and view the results in a photo gallery. This tutorial should take you less than half an hour to follow along with!
Scoop.it!
Ember.js's built in objects and structure are great, to use them correctly is to enjoy all it's power. So you wonder, what is the best way to use Ember.js's and it's well grounded structure to build your user's authentication? This article will not cover the authentication api part, because it's already well covered on good articles like codeberry's Authentication With EmberJS - Part 1, which we will use in this example, but we'll use the rails gem instead of the rails-api gem to make use of the assets pipeline. The part two on that article deals with the authentication task through EmberJS with an AuthManager component, which is clever idea, but it follows a path that leads to deal with the authentication part as a component, which leads to step outside of the framework's path in some cases, like accessing the store object outside of a route or controller. And it can lead to some problems or difficulties in the future.
Scoop.it!
The Ember run loop is an extremely important part of Embers internals. The run loop is used to batch, order and work in a way that's most efficient. Before we can understand why we should care, we need to understand...
Scoop.it!
Every journey starts with a beginning Which leads to the right(ish) part, in my opinion the right way to use a library/framework is to use it in it's full. As Ember.js provides a great range of tools and APIs to help us develop our applications I always take a deep dive in the Ember Guides before developing something new. For this particular subject, file upload, there is one thing missing there though, which is Ember.RSVP API does not have support for progress. So, after a long discussion with myself, I came to the conclusion that this time I would go a little bit around the framework to accomplish the task. So without any further ado, lets get to this, quite long, journey.
Scoop.it!
Real-world Adapter Patterns To show you how this pattern could be applied in the real-world – Ember apps in particular – I made a Hacker News extension for Chrome. It is available from the chrome web store, or you can just try it online here. You can also find the source code on GitHub. Once you have it installed, every time you visit Hacker News from Chrome, the extension will take over and present you with a better reading interface built with Ember.js.
Scoop.it!
Where we are In my last post, I put forth the argument that the new data flow story of ember next does not go far enough. I now want to suggest a way …
Scoop.it!
The component driven, performance focused approach of React is a perfect complement to the modularity and portability of native HTML Web Components. At first glance, React and Web Components might seem like two radically different solutions to the same problem. But when combined properly they complement each other to create an extremely powerful, expressive framework for developing complex web applications.
Scoop.it!
This is a follow up post to the History Store in Flux post where I described how I created my own History store In Flux. Using React Router for your routing and browser history is a much safer option then doing it yourself hence why I use it now in projects. React Router is very easy to set up and use but requires a few extra steps to get it working in Flux.
Scoop.it!
In JavaScript, functions are first-class entities: You can store them in data structures, pass them to other functions, and return them from functions. An amazing number of very strong programming techniques arise as a consequence of functions-as-first-class-entities. One of the strongest is also one of the simplest: You can write functions that compose and transform other functions.
Scoop.it!
Learn how Graph DB, Node JS, Angular and Express can be used to create next generation application. This article introduces you to the ANNE Stack – Angular JS, Neo 4J, Node Js and Express
Scoop.it!
Architecting your Angular application with reusable components can be complicated. Many times, UI components that need multiple entry points for user markup and the standard ng-transclude do not do enough of what is required. Using Web Component standards, like the Shadow DOM, we can now enable our applications to easily handle this.
|
Scoop.it!
Scoop.it!
Webpack is an amazing tool. It calls itself a "module bundler" but it is much more than that: it provides an infrastructure for building, transforming, and live updating modules. While its wall of configuration options may not be your style, this approach works really well for the problem it's solving.
Scoop.it!
Today we are going to dive into creating a simple application with Facebook authentication using ember-simple-auth and Torii. Ember Simple Auth is a lightweight library for implementing authentication with Ember.js applications. It handles all the session data and makes it really easy to authenticate against external providers or your own server. For the purposes of this tutorial we'll stick with authenticating against Facebook. Torii is a set of abstractions that is built with a number of providers and a session manager. We'll be using the facebook-oauth2 provider that comes with Torii.
Scoop.it!
Authentication is tricky, so why not have someone else handle it for you? Emre Guneyler shows you how to let users log in to your Ember.js app using Twitter In this article I will demonstrate how to implement sign in with Twitter and how to handle user sessions with Torii. Twitter uses OAuth 1.0a for authentication, which doesn’t require much client-side setup (just the pop-up and the session management). It does however require a significant server-side component for which I will use Sinatra.
Scoop.it!
Stefan Penner is an Ember.js core team member, a Principal Software Engineer at Yahoo, and a prolific open source contributor to many projects including ember.js, ember-cli, ember-data and Babel.js.
Jan Hesse's insight:
Scoop.it!
From
github
mvstar-compare - A brief comparison of a few MV* front end frameworks Scope Documentation - How well do they document their API?
Scoop.it!
If you are new to Ember then this might seem like a lot to manage, but actually it is quite the opposite. All these things have meaning. They all have their own folder in my app, and just by naming them correctly Ember CLI magically wires them all together into a working application. My favorite thing about Ember is how it can take away the pointless choices, and nothing is more pointless then deciding where to put a thing, or what to call it. However, it is not all rainbows and unicorns. There have always been these pesky things in real apps that don’t fit neatly into one of Ember’s buckets. They usually need to be used from multiple parts of your app, think logging, analytics, sessions, authentication, etc. Up until Ember 1.10 you had two basic approaches for these shared objects.
Scoop.it!
My friends started using it, Stride clients started asking for it, and it's
Scoop.it!
When doing real world web apps, there is a very common pattern: single source of truth shared by multiple clients. The best example of this is a chat: the message list, and the user list, must be readable and kept up to date for every connected client. Lets assume for a moment that all your clients are React apps executed in the same browser window. Then its easy: just use Flux! All clients will update their components every time the stores representing the message list and the user list is updated. Message posting will just be an action dispatch, as well as users joining or leaving a room. The problem is that all your clients are not in the same browser window. They actually are on different computers, on different hosts, and their only means of interacting with the server it through asynchronous communication (typically HTTP requests). This seems like a hard problem. Or is it?
Scoop.it!
Isomorphic apps isn’t just about writing the code once; its more about maintaining a consistent codebase without having to double-check every single modification in your client or server code to make sure its consistent. In 2015, server-side rendering is simply not an option: being able to deliver HTML that is consistent with you client-side-JS-powered app is mandatory for any public-facing moderately large product, for SEO and mobile performance if not for desktop time to first interaction and accessibility. Anybody who has tried to use PhantomJS or Selenium for server-side rendering at scale also knows that its simply not viable in practice. The most important problem is data fetching. If all your components are purely local, ie. they don’t depend on remote data fetching, then React.renderToString works great. But in the real world, you most certainly need to wire your components with data from your backend: SQL server, HTTP API, or whatever central data repository you’re using. And data fetching is, by nature, asynchronous. It can rely on sql.query or xhr or whatever fetching mechanism you’re leveraging. But React.renderToString is synchronous. This means it doesn’t make sense to write something like this...
Scoop.it!
As our business grows, we are seeing more and more complex use-cases that put our UI under stress, such as hundreds of metrics and dimensions that make the rendering of the app in a localised place really challenging. We decided to tackle these problems in-depth, and came up with what we think is a balanced approach between React and AngularJS.
Scoop.it!
Javascript is an ever-growing language, especially now that releases for ECMAScript specifications now operate on a yearly release schedule. As such the importance of needing to know Javascript beyond just jQuery becomes even more important as the language grows in scope and quite quickly. Contents:
|
