Next.js is a powerful framework for building server-side rendered applications. Next.js is just a wrapper around React, but it abstracts away all the ugly bits of React: build systems, transpilation, routing, CSS, etc. Most importantly, it makes server-side rendering with React dead simple, no need to carefully structure your code for use with preact-render-to-string or figure out the
lastChild pattern for replacing the server-side rendered component with the client-side rendered component. In this article, I'll show you how to build a basic Next.js app with server-side rendering on top of an Express and MongoDB API.
Async/await makes it easy to integrate asynchronous behavior with imperative constructs like for loops, if statements, and try/catch blocks. Unfortunately, it doesn't do the same for functional constructs like
Firebase is a great tool for getting data from a server to a client. Firebase handles caching, retries, socket management, and all the other unpleasant details of getting data to a client with spotty internet connection. In particular, Firebase is excellent for mobile web and mobile apps. In this article, I'll walk you through using Firebase with Preact, a lightweight React alternative, to build a simple app with server-side rendering.
Node.js 6.6.0 added a sporadically useful bug/feature: logging unhandled promise rejections to the console by default. In other words, the below script will print an error to the console:
By virtue of the event loop, scheduling tasks in Node.js is relatively straightforward. Plain old
setInterval() are sufficient for many basic use cases where you would normally use cron. However, things get more interesting when you need durable transactional scheduling, for use cases like:
I find the existence of tools like nvm baffling. I could understand if setting up Node.js required an actual installer or compiler or python, but node has pre-built binaries for most operating systems. Node and npm are both portable standalone executables, so all you need is the right binary for your OS in the right place on your file system. Especially if you're switching back and forth between Node 6.x and 7.6.0 for async/await, you should simplify your node version management workflow rather than using yet another bloated tool.
Async/await in Node.js opens up a host of powerful design patterns. Tasks that used to take complex libraries or intricate promise chaining can now be done with rudimentary
if statements and
for loops. I already wrote about these kind of design patterns with co, but async/await makes these patterns accessible in vanilla Node.js, no outside libraries required.
Arguably the biggest new feature in Node.js 7.6.0 is that the much awaited async function keyword is now available without a flag. Callback hell and promise hell are now in the past. But, like Uncle Ben always reminded us, with great power comes great responsibility, and async/await gives you a lot of new and exciting ways to shoot yourself in the foot. You still need to handle errors and be aware of the async nature of your code, otherwise you'll inevitably be complaining about "async/await hell" in 6 months.
The most important feature of most server-side frameworks is middleware: the ability to hook your own logic into the framework's logic, like IFTTT for your code. Express, Mongoose, Rails, and Django all rely heavily on middleware. LoopBack and Sequelize have hooks, AngularJS has parsers and interceptors, Hapi has extensions, but these are all just roses by another name. Except Hapi, Hapi by any other name would still have a foul code stench.
saveErrorIfNotFound option and
$where property in mongoose 4.8 gives plugins a powerful new way to modify the behavior of
save(). This feature may not seem as exciting as
eachAsync() or the major perf improvements in 4.8, but I think it will help the community develop some handy abstractions on top of
save(). How do these
MongoDB 3.2 supports 3 numeric types: 32 bit integers, 64 bit integers, and 64 bit binary floating points. MongoDB 3.4 introduces a
On a sunny Wednesday in September 2006, I showed up for my first day of an
Proxies are a powerful ES2015 feature that let you intercept operations on object properties by defining "traps" (function handlers) for getting/setting a property. For example:
Ramda is quickly becoming an indispensible part of my node projects. Lodash is more accessible and beginner-friendly, but ramda is far more powerful and expressive once you wrap your mind around it. In this article, I'll take a look at the
applySpec() function and how it can replace dependency injectors like wagner.
One particularly neat feature of mongoose is the chainable query builder API. This API provides the ability to build up MongoDB queries with helper methods, rather than via a JSON object.
Mongoose 4.5.0 introduces the ability to handle errors in middleware. This lets
If you haven't heard the React Native hype train yet, you will: it's probably
Co is a powerful tool for writing callback-free async code using vanilla ES2015. However, the sheer extent
The practice of asking brainteasers in interviews is a common punching bag
There's a lot of solutions out there for putting private projects in your
$httpBackend service is definitely one of my top 10 AngularJS features. It makes TDD incredibly easy, especially if you're testing directives as a whole.
React Native is hot right now,
Getting data into and out of MongoDB is a pain. Although MongoDB 3.0 and 3.2
I must confess, I really don't like most tech books. Except for
2015 was a big year for mongoose. Mongoose 4.0 was released, the first major
In last week's article, you
MongoDB 3.2.0 was released earlier this week. It includes some exciting
GridFS is a mechanism for
In the first two articles in this series, you built a
Strict unit tests are an interesting subject. They're simple, elegant, and do
I've spent a fair amount of time lauding Travis as an excellent go-to CI tool. But, when I wanted to use Travis
One of my favorite underused mongoose features is
Every so often I run into an npm module that uses
People have often asked me about my biggest pain points with AngularJS.
Last December, I switched my blog over to a static page generated by a vanilla NodeJS script. So far, its been a dream come true. Thanks to Cesar Devers' design skills, the blog is far more readable than the old standard WordPress template. Also, I can write my posts in Markdown, which has done wonders for my workflow. I also have more direct control over my layout and analytics, so I can use KeenIO to track some basic metrics. Getting to this new blog infrastructure was an adventure. I had brief flings with many static site generators before settling on my current setup. In this article, I'll explain why I decided to skip out on all the established tools and just write my own solution.
Recently, I've been looking into StrongLoop's LoopBack framework. LoopBack generates Express REST APIs by asking you a few simple questions at the command line. LoopBack lets you swap out different storage layers. For each model you define, you can choose to store it in MongoDB, Oracle, MySQL, or Microsoft SQL Server (or even in memory). Say you decide to store your users in MongoDB but your user's gift cards in MySQL (for transactions). Even if you started writing your code with gift cards stored in MongoDB, LoopBack's database abstraction layer makes switching a one-liner. Furthermore, LoopBack has SDKs for generating REST API clients in AngularJS, Android, and iOS. In short, LoopBack is a powerful tool for generating REST APIs that you can extend to scaffold client-side code.
Mongoose 3.9.7 has just been released. While I did say that 3.9.6 would be the
In case you haven't come across Petko Petkov's post on injection attacks against MongoDB and NodeJS yet, its definitely worth a careful read. In this article, he explains a pretty simple exploit that I suspect affects a fair number of applications, including some that I've implemented.
Two weeks ago marked a big milestone: mongoose 3.9.0 was released. Be warned, mongoose's versioning practice is that even numbered branches are stable and odd are unstable. While all our tests check out on 3.9.0, I would recommend sticking to 3.8.x releases in production for now. 3.9.0 was mongoose's first unstable release since October 2013. While the changes in 3.9.0 were relatively minor, they open the door to getting some interesting features into 4.0. Here are some of the high-level features I think should make it in to 4.0:
I have an important announcement to make: over the last couple weeks I've been taking over maintaining mongoose, the popular MongoDB/NodeJS ODM. I have some very big shoes to fill, Aaron Heckmann has done an extraordinary job building mongoose into an indispensable part of the NodeJS ecosystem. As an avid user of mongoose over the last two years, I look forward to continuing mongoose's storied tradition of making dealing with data elegant and fun. However, mongoose isn't perfect, and I'm already looking forward to the next major stable release, 4.0.0. Suggestions are most welcome, but please be patient, I'm still trying to catch up on the backlog of issues and pull requests.
From a performance perspective as well as a developer productivity perspective, MongoDB really shines when you only need to load one document to display a particular page. A traditional hard drive only needs one sequential read to load a single MongoDB document, which limits your performance overhead. In addition, much like how Nas says life is simple because all he needs is one mic, grouping all the data for a single page into one document makes understanding and debugging the page much simpler.
MongoDB shipped the newest stable version of its server, 2.6.0, this week. This new release is massive: there were about 4000 commits between 2.4 and 2.6. Unsurprisingly, the release notes are a pretty dense read and don't quite convey how cool some of these new features are. To remedy that, I'll dedicate a couple posts to putting on my NodeJS web developer hat and exploring interesting use cases for new features in 2.6. The first feature I'll dig in to is text search, or, in layman's terms, Google for your MongoDB documents.
Displaying prices in different currencies is a common internationalization task for web developers. However, this task can be a bit tricky:
In last week's blog post, I showed you how to install all of the basic tools that you need to get up and running with the MEAN Stack. Didn't catch that one and need help getting started with the MEAN Stack? You can find everything you need in Introduction to the MEAN Stack, Part One.
I've received several emails asking for instructions on how to set up a basic MEAN stack app. I'm going to take it one step further and give you guys a two-part post that will walk you through creating your first MEAN stack app- from installing the tools to actually writing the code. In Part One we'll go through the setup and installation process. Next in Part Two we'll walk through the steps for building a very simple to-do list. Part One consists of seven steps, although only the first two are are strictly necessary.
If you're familiar with Ruby on Rails and are using MongoDB to build a NodeJS app, you might miss some slick ActiveRecord features, such as declarative validation. Diving into most of the basic tutorials out there, you'll find that many basic web development tasks are more work than you like. For example, if we borrow the style of http://howtonode.org/express-mongodb, a route that pulls a document by its ID will look something like this:
This post was featured as a guest blog post for MongoDB on April 30th 2013, which can be found here