Introduction to antipatterns

This section is about common antipatterns that are observed as part of the API proxies deployed on the Apigee Edge platform.

The good news is that each of these antipatterns can be clearly identified and rectified with appropriate good practices. Consequently, the APIs deployed on Edge would serve their intended purpose and be more performant.

Summary of antipatterns

The following table lists the antipatterns introduced by this section:

Category Antipatterns
Policy antipatterns
Performance antipatterns
Generic antipatterns
Backend antipatterns

What is an antipattern?

Wikipedia defines a software antipattern as:

format_quote

In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.

format_quote

Simply put, an antipattern is something that the software allows it’s "user" to do, but is something that may have adverse functional, serviceable or performance affect.

For example, consider the omnipotent-sounding "God Class/Object".

In objected oriented parlance, a god class is a class that controls too many classes for a given application.

For example, consider an application with the following reference tree:

Figure 1: God class

As the image illustrates, the god class uses and references too many classes.

The framework on which the application was developed does not prevent the creation of such a class, but it has many disadvantages, the primary ones being:

  • Hard to maintain
  • Single point of failure when the application runs

Consequently, creation of such a class should be avoided. It is an antipattern.

Target audience

This section best serves Apigee Edge developers as they progress through the lifecycle of designing and developing API proxies for their services. It should ideally be used as a reference guide during the API development lifecycle and during troubleshooting.