Do you dream of a local development environment that’s easy to configure and works independently from the software layers that you are currently not working on? I do!
As a software engineer, I have suffered the pain of starting projects that were not easy to configure. Reading the technical documentation does not help when much of it is outdated, or even worse, missing many steps. I have lost hours of my life trying to understand why my local development environment was not working.
An ideal scenario
As a developer, you have to meet a few prerequisites before contributing to a project. For instance, you must agree to the version-control requirements, and you need to know how to use the project IDE, how to use a package manager, and so on.
But nothing more. You don’t need to learn a poorly documented, made-in-house framework just to satisfy the ego of an architect who wanted to reinvent the wheel. You don’t need to run an external virtual machine to emulate the production environment. As a developer, you are free to invest your time in improving the code and adding value to the product.
A developer-centered approach to application development
My goal with this article is to describe strategies for building an Angular 8 application in a way that centers the developer experience.
Continue reading “A developer-centered approach to application development”
On April 21st, Node.js released its latest major version with Node.js 14. Because this is an even-numbered release, it will become a Long Term Support (LTS) release in October 2020. This release brings a host of improvements and features, such as improved diagnostics, a V8 upgrade, an experimental Async Local Storage API, hardened the streams APIs, and more.
While Red Hat will release a Universal Base Image (UBI) for Node.js 14 in the coming months for Red Hat OpenShift and Red Hat Enterprise Linux, this article helps you get started today. If you’re interested in more about Node.js 14’s improvements and new features, check out the article listed at the end.
Continue reading “Use Node.js 14 on Red Hat OpenShift”
With the rise of social networks and people having more free time due to isolation, it has become popular to see lots of maps and graphs. These are made using big spatial data to explain how COVID-19 is expanding, why it is faster in some countries, and how we can stop it.
Continue reading Working with big spatial data workflows (or, what would John Snow do?)
Many front-end developers are discovering the benefits of contract-first development. With this approach, front- and back-end developers use OpenAPI to collaboratively design an API specification. Once the initial specification is done, front-end developers can use API definitions and sample data to develop discrete user interface (UI) components. Defining a single OpenAPI spec improves cross-team collaboration, and API definitions empower front-end developers to design our initial workflows without relying on the back end.
Continue reading Contract-first development: Create a mock back end for realistic data interactions with React
Red Hat single sign-on (SSO)—or its open source version, Keycloak—is one of the leading products for web SSO capabilities, and is based on popular standards such as Security Assertion Markup Language (SAML) 2.0, OpenID Connect, and OAuth 2.0. One of Red Hat SSO’s strongest features is that we can access Keycloak directly in many ways, whether through a simple HTML login form, or an API call. In the following scenario, we will generate a JWT token and then validate it. Everything will be done using API calls, so Keycloak’s UI is not exposed to the public directly.
For the past two years, Red Hat Middleware has provided a supported Node.js runtime on Red Hat OpenShift as part of Red Hat Runtimes. Our goal has been to provide rapid releases of the upstream Node.js core project, example applications to get developers up and running quickly, Node.js container images, integrations with other components of Red Hat’s cloud-native stack, and (of course) provide world-class service and support for customers. Earlier this year, the team behind Red Hat’s distribution and support of Node.js even received a “Devie” award from DeveloperWeek for this work, further acknowledging Red Hat’s role in supporting the community and ecosystem.
Red Hat Node.js experts at your fingertips
Red Hat collaborates in more ways than one with the fastest growing runtimes used in business-critical applications on the cloud by contributing to the community, being part of the Technical Steering Committee, and even participating and driving strategic initiatives to carve the future of Node.js. Combining this work with our Red Hat Enterprise Linux (RHEL) and OpenShift expertise, we can help you reach your goals of delivering and supporting business-critical applications on and off the cloud.
Continue reading “Red Hat support for Node.js”
I recently wrote articles on deploying an Express.js application to OpenShift, how to debug your Node.js application on OpenShift with Chrome Dev Tools and a short series on deploying modern web applications to OpenShift. All of those articles used a node module called Nodeshift, but I did a Jedi, hand-wavy thing when talking about it. This next series of articles takes a deeper look at what Nodeshift is and how it is used to ease the deployment of Node.js apps to OpenShift during development.
Continue reading “Easily deploy Node.js applications to Red Hat OpenShift using Nodeshift”
Before anything like an Android device or iPhone existed, desktop computers were the battleground for the browser wars. The battle involved billions of dollars invested by a number of companies, all based on the premise that whoever ruled the desktop browser market would own the internet. Today, mobile devices account for nearly half of all website traffic. Back in the 1990s, however, almost all of the action on the web came from desktop machines, and the vast majority of those desktop machines were running some flavor of Microsoft Windows.
In the browser world, the first-mover advantage belonged to Netscape Communications Corporation. They built the Netscape Navigator browser that made the web accessible to millions for the first time. Netscape had more than 80% of the market, but they also had no shortage of competition. IBM had a browser for OS/2. Oracle had the Powerbrowser, a Netscape-compatible product that included something called the Database Markup Language. The real danger to Netscape, of course, came from the company that owned more than 80% of the world’s desktops: Microsoft.
Strategically, Netscape realized that the web needed to move past static web pages to reach its full potential. Even if they were created dynamically by something like a CGI script on the web server, pages didn’t change once they arrived in your browser. If you wanted to see even a slightly modified version of a page, you had to send a request back to the server and wait for a response. For all its sophistication, a web browser felt a lot like a dumb terminal attached to a mainframe. What web developers needed was a programming language that would run in the browser, taking advantage of the processing power of the desktop machine to give users a richer experience.
Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”