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:
What is an antipattern?
Wikipedia defines a software antipattern as:
In software engineering, an anti-pattern is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.
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:
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.
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.