Blog

Users want to work on devices and systems of their choice. With the integrated development environment RAD Studio, you can create native apps for all relevant systems. In this article, we will take a look at its potential uses, advantages, and disadvantages.

Your company’s approach to APIs should be central to any vision of best practices. However, the emergence of multiple protocols and tools has brought challenges to maintaining API quality and consistency. Many teams lack confidence in developing consistent, secure, and high-quality APIs.

It’s been a few weeks since we wrapped up another great edition of the API Conference but we still remember the amazing talks! One of them was Erik Wilde's keynote, “API Anti-Patterns: WD-40 for Your Digital Initiatives”, where he looks at the most important aspects of API management and illustrates which problems jeopardize the success of API management, and ultimately of digital initiatives. 

After several years on the market, GraphQL is now a mature and established alternative to REST. You should consider it when creating or further developing an API. Many applications such as Facebook, Instagram, and XING already successfully use this REST alternative [1]. That’s a good reason to provide insights into how GraphQL can be integrated into modern serverless architectures, with minimum effort. A highly scalable implementation is presented in the interaction between GraphQL with AWS Lambda. It can be adapted to various architectures and frameworks.

So you’ve decided to attend API Conference but you don’t know how to break it to your boss that it is a win-win situation? Don’t worry, we’ve got you covered. Follow 4 simple steps and use these 5 arguments to show why your organization needs to invest in API Conference!

We spoke with Daniel Bryant about how API gateways have evolved, what impact microservices has on APIs, service meshes, and more. What are the biggest challenges when deploying and working with API gateways and what helpful tips does Daniel Bryant offer?

More than twenty years after its "invention" by Roy Fielding, RESTful API design is more relevant than ever. No matter if it’s in the environment of microservices or opening up systems previously only used internally - REST is everywhere you look! But what exactly is REST? Just because a JSON or XML payload is sent to or received from a server via HTTP does not mean that it is a RESTful API. So what exactly is a REST interface? And at what point can we say that it is truly successful? This question is dividing opinions.

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.