MageConf 2017, Design API Best Practices

© 2017 Magento, Inc. Page | 1 ‘17
API Design
Best practices
Igor Miniailo
Magento Architect

Why is API so crucial?

Semantic Versioning
Version numbers are in the format
MAJOR.MINOR.PATCH, where:
– MAJOR indicates incompatible API changes
– MINOR indicates backward-compatible
functionality has been added
– PATCH indicates backward-compatible bug
fixes

The backward compatibility policy
applies to PHP code annotated with
@api

Public and Private code

Public vs Private code
Private code is not supposed to
be used by third party modules,
so, in most cases, its
modifications will only trigger
PATCH version bumps.
Changes in public code always
trigger MINOR or MAJOR
version bumps.

What examples of Public code Magento has?
• PHP Interface (marked with @api)
• PHP Class (marked with @api)
• Javascript Interface (marked with @api)
• Javascript Class (marked with @api)
• Virtual Type (marked with @api)
• URL paths
• Console commands and their arguments
• Less Variables & Mixins
• Message queue topics and their data types
• UI component declarations
• Layout handles declared by modules
• Events triggered by component (both static dynamic)
• Schema of configuration types introduced by module
• Structure of System Configuration fields used by module

API vs SPI (Extension Points)
A PHP Interface in Magento can be used several ways by the core
product and extension developers.
• As an API. is a set of interfaces and their
implementations that a module provides to other
modules
• As a Service Provider Interface (SPI). is a set of
interfaces that a module uses internally and allows their
implementation by other modules.
• As both. APIs and SPIs are not mutually exclusive.

After the code is released, both API and SPI can
be evolved in a backwards-compatible way. But
both have their specific limitations.

We do not distinguish them separately.
SPIs are annotated the same as APIs.

Who decides whether interface/class belong to API or SPI?
YOU

Dependency Rules API
If a module uses (calls) an API, it should be dependent on the MAJOR
version.
API dependency example
{
...
"require": {
"magento/module-customer": "~100.0", // (>=100.0 <101.0.0)
},
...
}

Dependency Rules SPI
If a module implements an API/SPI, it should be dependent on the
MAJOR+MINOR version.
SPI dependency example
{
...
"require": {
"magento/module-customer": "~100.0.0", // (>=100.0.0 <100.1.0)
},
...
}

http://devdocs.magento.com/guides/v2.1/release-notes/backward-
incompatible-changes-2.1.html

Prohibited Code Changes

• Interface/class removal
• Public & protected method removal
• Introduction of a method to a class or
interface
PHP - Prohibited Code Changes

MagentoCatalogApiCategoryRepositoryInterface

MagentoCatalogApiCategoryListInterface

• Static function removal
• Parameter addition in public methods
• Parameter addition in protected
methods

• Method argument type modification
• Modification of types of thrown
exceptions (unless a new exception is
a subtype of the old one)
• Constructor modification

class ExistingClass
{
/**
* @var NewDependencyInterface $newDependency
*/
private $newDependency;
public function __construct(
OldDependencyIntreface $oldDependency,
$oldRequiredConstructorParameter,
$oldOptinalConstructorParameter = null,
NewDependencyInterface $newDependency = null
) {
...
$this>newDependency = $newDependency ?: MagentoFrameworkAppObjectManager::getInstance()
->get(NewDependencyInterface::class);
...
}
public function existingFunction() {
// Existing functionality
...
// Use $this->newDependency wherever the new dependency is needed
...
}
}

• Modifying the default values of
optional arguments in public and
protected methods
• Removing or renaming constants

The main rule is that backwards compatibility
is more important than niceness and effort of
the implementation.

Coupling Between Objects Reaches Its Limit with
a New Dependency

We MUST do continuous Refactoring!
Backward Compatibility should not be an excuse
for not doing refactoring!

Backward Compatible Fix
*it works (most of the time), but code quality
is far from good enough

Good object oriented programming in the service layer is basically
functional programming:
• constructor injection
• immutable state
• single responsibility principle
• uniform interfaces
• value objects passed across services
Bringing these concepts to an extreme leads to single-method,
immutable objects.

Ubiquitous language matters

Why to use `execute` but not __invoke?

Proposal to move towards Functional Objects

Pros
The main reason for __invoke usage proposal was elimination of
unneeded `execute` methods,
which look a bit artificial and redundant here

Cons
No autocomplete in
PHP Storm IDE
accessing via $this

Cons

Cons
Unit tests look frustrating and non intuitive

Repositories
In Magento 2 Repositories are considered as an implementation
of Facade pattern which provides a simplified interface to a larger body
of code responsible for Domain Entity management.
The main intention is to make API more readable and reduce
dependencies of business logic code on the inner workings of a
module, since most code uses the facade, thus allowing more flexibility
in developing the system.

Repositories

Good API design
Don't make your client do anything you can do
for them (this reduces the amount of boilerplate
code your client will have)

Q & A
@iminyaylo
engcom@magento.com

MageConf 2017, Design API Best Practices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à MageConf 2017, Design API Best Practices

Similaire à MageConf 2017, Design API Best Practices (20)

Dernier

Dernier (20)

MageConf 2017, Design API Best Practices

Notes de l'éditeur