🔥 Tech Blips #23.10
In this technology newsletter: Architecture Significant Test, DGS Framework, Mocks Server and CloudEvents.
I'm pleased to bring you the latest Tech Blips, the monthly technology newsletter for CTOs, tech leads, software architects and software engineers - in short, for all technology enthusiasts!
As a software architect, you are constantly confronted with a variety of requirements and tasks that you must analyse to determine if they are relevant to the work of software architecture. This is where the Architectural Significant Test technique comes into play. It helps you as a software architect and software developer to check in a lean and effective way whether a requirement or a task is significant for the software architecture work.
When you build a web frontend against a web api, you often implement the backend logic at the same time, which is not yet fully available. So only the (e.g. Open API) contract is already available. As a web front-end or consumer of that API, it helps you to develop against a mock implementation and access mock data. This is exactly what the Mocks Server helps you with. An easily configurable mock server that provides you with mock data in an efficient way.
GraphQL is gaining more and more importance. Even in the Java and Spring ecosystem. In recent years, Netflix has been working on the GraphQL framework DGS Framework for Spring Boot. It's worth taking a look at it.
Events are everywhere. However, event producers tend to describe events differently. CloudEvents is a specification for describing event data in a uniform way. CloudEvents aims to dramatically simplify the declaration and delivery across services, platforms and beyond!
Kind regards
As a software engineer with architecture responsibilities or as a software architect (see also Do we need a software architect in our agile team?), you want to prioritize technical issues quickly so that architecturally significant issues are addressed at their most responsible moment and we don't have to revise decisions and designs unnecessarily later.
In doing so, you want to be as objective as possible to avoid loud voices getting more attention than they deserve so that the truly urgent and important things are addressed first.
The time budget per issue is at most one to two minutes, as it is not uncommon to be confronted with up to 20 issues per day.
All these engineering issues can be evaluated against the architecturally significant requirements (Source: Architectural Significance Test Blog Post):
1. The requirement is directly associated with high business value (benefit vs. cost) or business risk.
2. The requirement is a concern of a particularly important stakeholder such as the project sponsor or an external compliance auditor.
3. The requirement includes Quality-of-Service (QoS) characteristics at runtime (e.g., performance requirements) that are significantly different from those already met by the evolving architecture.
4. The requirement causes new or deals with one or more existing external dependencies that may have unpredictable, unreliable, and/or uncontrollable behavior.
5. The requirement is cross-cutting and therefore affects multiple parts of the system and their interactions; it may even have short- and/or long-term system-wide implications (examples: security, monitoring).
6. The requirement has a "First-of-a-Kind" (FOAK) character: for example, this team has never built a component or subsystem that meets this particular requirement.
7. The requirement has been troublesome and has led to critical situations, budget overruns, or customer dissatisfaction on a previous project in a similar context.
Using these requirements, you can evaluate each issue in the backlog against these criteria (this is not a quantitative technique, but the Architectural Significant Test merely makes previously tacit knowledge explicit (“worst first”)).
Defining API responses in the earliest stages of development improves communication between team members and aligns their expectations. Controlling responses improves development flow and avoids early dependencies with the team developing the API. It also improves testing of error cases or other cases that are usually difficult to reproduce in a real API.
Mocks Server allows you to define many different responses for the same route. So you can change the entire behavior of the mocked API by simply changing the response of one or more routes while the server is running.
Managing different responses for the same route and the ability to store different collections makes it easy to switch between many predefined API state simulations.
This is perfect for developing an API client, because the interactive CLI can be used to change all API responses at once, or a single response without changing the code. And it's also perfect for running tests, because the different collections of route variants can be used to test different scenarios.
mocks-serverMock Server on GitHub
Netflix has been developing a GraphQL framework for Spring Boot for the last few years. They have decided to release this project as open source. It is said to be the best way to implement GraphQL servers in Java.
The Domain Graph Service framework is easy to use, has many features and is well supported. DGS is a good choice for any Java developer who wants to build a GraphQL server. Thanks to the annotation-based Spring Boot programming model, it is easy to use and offers a wide range of features, including test framework, code generation, federation, security, subscriptions, file uploads, error handling and many extension points.
The focus is on a great developer experience, while it is also battle-tested by Netflix.
A short introduction in the Netflix Domain Graph Service Framework
NetflixDGS Framework on GitHub
NetflixDGS Example in Java
Events are everywhere. However, producers of events tend to describe events differently.
Since there is no standard for describing events, developers have to keep learning how to use events. This also limits the potential of libraries, tools, and infrastructures that support the delivery of event data in different environments, such as SDKs, event routers, or tracing systems. The overall portability and productivity that can be achieved with event data is hindered.
CloudEvents is a specification for describing event data in common formats to ensure interoperability between services, platforms, and systems.
Event Formats specify how to serialize a CloudEvent with certain encoding formats. Compliant CloudEvents implementations that support those encodings MUST adhere to the encoding rules specified in the respective event format. All implementations MUST support the JSON format.
For more information on the history, development and design rationale behind the specification, see the CloudEvents Primer document.
CloudEvents Project: A Step Towards Serverless Interop
CloudEvents: One Event to Rule Them All
cloudeventsCloud Events Primer
cloudeventsCloudEvents on GitHub
Comments ()