Observability is Key
One of the great things about Node.js is how well it performs in a container. Its fast start up time, and relatively small size make it a favorite for microservice applications on OpenShift. But with this shift to containerized deployments comes some complexity. As a result, monitoring Node.js applications can be difficult. At times it seems as though the performance and behavior of our applications become opaque to us. So what can we do to find and address issues in our services before they become a problem? We need to enhance observability by monitoring the state of our services.
Instrumentation of our applications is one way to increase observability. Therefore, in this article, I will demonstrate the instrumentation of a Node.js application using Prometheus.
Continue reading “Monitoring Node.js Applications on OpenShift with Prometheus”
What does this mean for your enterprise? Where does it fit, and how can Red Hat OpenShift Application Runtimes help you use this technology?
Join this session for the answers. We’ll also demonstrate how quickly you can set up non-trivial enterprise-grade Node.js applications on Red Hat OpenShift Container Platform. We’ll explore how to integrate with other open source technologies, such as Istio, and discuss strategies for your Node.js development and deployment pipeline, including canary and blue/green deployment strategies.
Register now and join the live presentation at 12 p.m. EDT, Thursday, April 19th.
Continue reading “Next DevNation Live: Enterprise Node.js on OpenShift, April 19th, 12 p.m. EDT”
For your end users, one of the most important aspects of your API is the perceived response time — if your mobile application takes an excessive amount of time to load data, users will get frustrated.
In this series of blog posts, we’ll cover three ways to approach building a RESTful API that leads to better user experience by minimizing perceived response time. These strategies include: processing requests quickly, reducing payload sizes, and eliminating requests entirely, or only downloading data that has changed. And, we’ll show you how to do each by providing sample node.js code that can be deployed ‘as is’ on Red Hat Mobile Application Platform to build a better mobile API.
But, before getting into each strategy, why are these important? The user interface (UI) and user experience (UX) are extremely important to the success of mobile applications.
Continue reading “Improving user experience for mobile APIs using the cloud”
In today’s fast paced world of business, delivering quickly is a top priority. Doing so is difficult, however, if you lack confidence in your codebase or rely on error prone deployment processes. Continuous integration enables development teams to automatically run test cases prior to merging code into a stable branch, while continuous deployment leverages automation to provide more reliable, faster deployments of that code.
Red Hat Mobile Application Platform supports an agile approach to developing, integrating, and deploying enterprise mobile applications—whether native, hybrid, or on the web. The platform supports collaborative development across multiple teams and projects, and a wide variety of leading tool kits and frameworks. You gain central control over security and policy management, the ease of Mobile Backend-as-a-Service (MBaaS) integration with enterprise systems, and a variety of cloud deployment options.
In this article we’ll demonstrate how a Red Hat Mobile Application Cloud Application or mBaaS Service can be configured for continuous integration (CI) via CircleCI, and for continuous deployment (CD) to the Red Hat Mobile Application Platform.
Continue reading “Continuous Integration and Deployment for Red Hat Mobile Cloud Applications using Circle CI”
Test-Driven-Development (TDD) is an increasingly popular, and practical, development methodology in today’s software industry, and it is easy to apply in Node.js – as we’ll see in this article. TDD forces much greater code test coverage, and if you aren’t already using it, I’d strongly encourage trying.
The process is: define a test that expects the output we want from our library, API, or whatever it is we’re testing to produce; ensure that the test fails – because we have not yet implemented any functionality; then write the implementation code required to make that test pass.
Continue reading “Test-Driven-Development for building APIs in Node.js and Express”