Before diving into the code, we need to consider whether Express is a good choice for the application we need to create. Next, we will check out a couple of good use cases for the framework.
The Web is constantly evolving, and nowadays, applications do more than talk to a single database and send HTML over the wire. An application could use an in-memory database for session storage and caching, a message queue for background processing, at least one relational/NoSQL database, and external services to store files, stream logs, and monitor application health. The handling of I/O bound operations is a great use case for Node because of its nonblocking nature, and this applies to Express as well. This means that we can easily integrate all these components into our project, and it will still have a solid performance.
Single-page applications represent web applications that don't reload the page when we use them. They update parts of their interface to provide a more native-like experience to end users.
There are many arguments for writing single-page applications in Express, which include the following:
It has the ability to handle a lot of concurrent requests per second
It's not a bloated framework; it has the bare minimum glue needed to write web applications
It has a lovely DSL syntax to describe routes
It can perform content negotiation, so we can have the same endpoint for our data but deliver different representations based on the client's request (JSON, XML, or others)
It has a lot of small functions that make our lives easier, such as
res.sendfile, which transfers a file to the client and sets the proper headers, andreq.xhr, which checks whether the current request has been transmitted using Ajax, and many others
Any Express application can be mounted onto another parent one, enabling us to create modular components that can be included in multiple applications. For example, we can create a user authentication system and reuse it for all our projects. Another situation where this can come in handy is when multiple people are working on the same project but each has different responsibilities; somebody could work on an API while a different person creates the multipage website, and each of them could use separate repositories for source control management. When a child application is finished, the master one can include it by adding a single line of code (okay, maybe two if we're declaring the first one as a dependency in the package.json file).
Writing application code that runs both on the server and on the client is a very hot topic right now, and has often been referred to as "The Holy Grail of Web Development". Besides eliminating code duplication, there is one other big advantage of using this approach with single-page applications: we can render the first page on the server and all the subsequent ones on the client. This improves the speed of the initial page load (so users don't have to wait until all the JavaScript code is loaded and executed) and is also SEO friendly and doesn't require us to resort to tricks such as proxying to a headless browser for crawlers. There have been several attempts to create frameworks that use the Backbone.js client-side API on top of Express, one of the most popular being Rendr (https://github.com/airbnb/rendr).
Since Express is a minimalist framework, we can use it to build more complex and opinionated solutions. In fact, there are lots of such MVC and real-time frameworks in the Node ecosystem. They offer advanced features that are packed into a single application, such as an ORM, middleware that boosts security, internationalization/localization, application life cycle middleware, a custom routing library, built-in view helpers, and so on. Another aspect to take into consideration is that these frameworks also impose certain conventions that we need to adhere to, the most notable being the application structure.
If there is any CPU-intensive task that is blocking the event-loop, it means that every single client making a request to the Express application will just hang until that task has finished. This happens because, unlike the Apache web server that spawns a thread per connection, Node uses an event loop, so all the requests run in the same thread.
If we want to create a regular CRUD-based application that has complex database relationships—and scaling thousands of concurrent requests isn't the primary goal—then using a full-stack framework is a better option (for example, Rails, Django, and CakePHP). That's not to say that we cannot achieve the same end result with Express, but we would have to include all the components ourselves.