InfoQ Homepage Web Development Content on InfoQ
-
Interactive Microservices as an Alternative to Micro Front-Ends for Modularizing the UI Layer
While microservices architectures are well established for the back-ends of software systems, the same cannot be said for front-ends. Interactive microservices are based on a new type of web API that Qworum defines, the multi-phase web API, where the endpoint calls may involve more than one request-response pair, also called a phase.
-
The Six Ways of Optimizing WebAssembly
While Wasm was originally designed for the browser, it turned out to be useful for embedded programming, plugins, cloud, and edge computing. For all these use cases, performance is tremendously important and is greatly impacted by file size. In this article, we’ll look at six ways to optimize Wasm for performance and file size.
-
Using Serverless WebSockets to Enable Real-Time Messaging
This article reviews some of the most common live-user experiences with examples, discusses event-driven architectures to support real-time updates, and introduces common technology choices.
-
Separation of Concerns in Node.js
In Node.js you can structure your code however you want. There is no "correct way". You have the option of writing all of your code in a single app.js file or creating multiple files and placing them in different folders. Most developers, however, would recommend structuring your projects by grouping related data together rather than having it all together.
-
Turning a Node.js Monolith into a Monorepo without Disrupting the Team
Splitting monoliths into services creates complexity in maintaining multiple repositories (one per service) with separate (yet interdependent) build processes and versioning history. Monorepos have become a popular solution to reduce that complexity.
-
InfoQ .NET Trends Report 2022
Every year, all InfoQ editors invite seasoned developers and practitioners from the industry to discuss the current trends in the entire software development landscape. In this article, we discuss some of the .NET Trends for 2022, divided into four stages of adoption.
-
The Compounding (Business) Value of Composable Ecosystems
Being “free” and open source doesn’t hinder the value of these projects to businesses and end users; rather it unlocks it. The composability of open source ecosystems allows the innovation and value of the whole ecosystem to compound on itself.
-
Two Must-Have Tools for Jakarta EE Developers
The wildfly-jar-maven-plugin and the brand new wildfly-datasources-preview-galleon-pack from the WildFly project are worthy of your attention. These tools add on-the-fly generation of an Uber JAR including configuration for containerization and datasources, and make it a pleasure to write applications for Jakarta EE and WildFly.
-
Writing Automated Tests on a Legacy Node.js Back-End
Let’s explore why some Node.js codebases are more challenging to test than others. Then, we explore several techniques to write tests that are simple, robust and fast to check the business logic, including inversion of control, approval tests and - spoiler alert - no mocks!
-
How to Create a Network Proxy Using Stream Processor Pipy
In this article we are going to introduce Pipy, an open-source cloud-native network stream processor. After describing its modular design, we will see how to rapidly build a high-performance network proxy to serve our specific needs. Pipy has been battle-tested and is already in use by multiple commercial clients.
-
Why Change Intelligence is Necessary to Effectively Troubleshoot Modern Applications
Change Intelligence is often a missing component in incident management. Successfully correlating monitoring and observability data to arrive allows engineers to arrive at the root cause more rapidly. Telemetry provides the building blocks that enable change intelligence to identify and map the root cause, based on changes in the system and their broader impact.
-
Lightweight External Business Rules
Complex enterprise applications usually come with varying business logic. Such conditions and subsequent system actions, known as rules, are ever varying and demand involvement of domain specific knowledge more than technology and programming. The rules must reside outside the codebase, authored by people with core domain expertise with minimal tech knowledge.