Blog

Large software systems usually do not exist alone and often have many partner systems calling its APIs. The number of partner systems can quickly reach double digits. The smaller the services are cut, which currently tends to happen in projects, the higher the number of partner systems that must be called. An extensive communication network is thus established: a so-called service mesh.

How do I actually test the interaction in my microservices landscape? How do I make sure that the right version of a service is deployed on the right stage? How do I keep an eye on the dependencies of my microservices? And how do I ensure that all clients continue to work as my APIs evolve? How can I be sure that an old version of an interface is no longer needed and can therefore be removed? Consumer-driven contracts promise a solution to all these questions, but come with significant complexity and have limitations of their own.

The enterprise world is characterized by web-based form applications. If you then consider using the same UI components multiple times in different applications, the use of framework-agnostic Web Components as a technical foundation is obvious. Web Components enable easy reuse and integration, but there are also a few stumbling blocks that need to be avoided.

Looking to 2020 and beyond, the proportion of data produced and consumed in realtime is growing exponentially.

In this article on the Shopware 6 e-commerce platform, we look at the technical changes in the new version and the new API First approach.

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed data exchange layer between information systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties.

When most people think of APIs for microservices, they think of HTTP-based, RESTful Web Services first. The REST paradigm is the predominant one when it comes to services publicly available on the Internet that many development teams deal with. It also fits quite well if the problem can be traced back to CRUD (Create, Read, Update, Delete) services in the broadest sense.

Most approaches to testing test individual examples. This is often not enough to tease out rare but realistic edge cases. As a result, it takes a large number of individual tests to really be confident that our API is ready for deployment: This is a lot of work. What if we could generate test cases automatically?