Talk about why the current API pattern is broken and how to fix shared IO state in distributed architectures and the architectural cross cutting concern as well as new patterns like API Chaining(tm)
2. Title TextFirst Lets Understand The Difference Between
Centralized and Distributed Architecturesā¦
Understanding The API Pattern
Owen Rubel owenr@uw.edu
3. Title Text
Centralized vs Distributed Architecture
Centralized Architecture (Unshared I/O)
Distributed Architecture (Shared I/O)
microservices
monolith application
monolith application
proxy MQapp
server
Owen Rubel owenr@uw.edu
Client Client
ClientClient
(CORS,security) (caching,security)
4. Title Text
Owen Rubel owenr@uw.edu
ā¢ How many developers still use a centralized architecture vs a
distributed architecture in their development?
Centralized vs Distributed Architecture
5. Title Text
Owen Rubel owenr@uw.edu
ā¢ How many developers still use a centralized architecture vs a
distributed architecture in their development?
ā¢ How many developers used a centralized architecture for their
development 5 years ago? 10 years ago?
Centralized vs Distributed Architecture
6. Title Text
Owen Rubel owenr@uw.edu
ā¢ How many developers still use a centralized architecture vs a
distributed architecture in their development?
ā¢ How many developers used a centralized architecture for their
development 5 years ago? 10 years ago?
ā¢ Over the last 20+ years, there has been a trend toward distributed
architectures due to separation of services/concerns, micro
services, and Aspect Oriented Programming
Centralized vs Distributed Architecture
7. Title Text
ā An API is Standardized Input/Output (I/O) to/from a
Separation of Concern (usually being Business
Logic).ā
In Short :
What Is An API? (1 OF 2)
Owen Rubel owenr@uw.edu
9. Title Text
ā In computer science, separation of concerns (SoC) is a
design principle for separating a computer program into
distinct sections, such that each section addresses a
separate concern. A concern is a set of information that
affects the code of a computer programā (ex HTML, CSS, JS)
- Source : Separation Of Concern, Wikipedia
What Is Separation of Concern? (1 of 2)
Owen Rubel owenr@uw.edu
10. Title Text
What Is Separation of Concern? (2 of 2)
Bound Secondary
Concern
(Communication
Logic)
Primary
Concern
(Business Logic)
Owen Rubel owenr@uw.edu
11. Title Text
API Pattern in Distributed Architecture
Bound I/O Data
and/or Functionality
Owen Rubel owenr@uw.edu
12. Title Text
!!!WARNING!!! CROSS CUTTING CONCERN
API Pattern in Distributed Architecture
Bound I/O Data
and/or Functionality
Duplicated I/O Data
and/or Functionality
Duplicated I/O Data
and/or Functionality
Owen Rubel owenr@uw.edu
13. Title Text
āCross-cutting concerns can be directly responsible for tangling, or
system inter-dependencies, within a program. Because procedural
and functional language constructs consist entirely of procedure
calling, there is no semantic through where two goals (the
capability to be implemented and the related cross-cutting concern)
can be addressed simultaneously.[3] As a result, the code
addressing the cross-cutting concern must be scattered, or
duplicated, across the various related locations, resulting in a
loss of modularity.[2]ā
- Source : Cross Cutting Concern, Wikipedia
What is a Cross Cutting Concern?
Owen Rubel owenr@uw.edu
14. Title Text
ā¢ Synchronization
ā¢ Real-time constraints
ā¢ Error detection and correction
ā¢ Product features
ā¢ Memory management
ā¢ Data validation
ā¢ Persistence
ā¢ Transaction processing
ā¢ Internationalization and localization which includes
Language localisation
ā¢ Information security
ā¢ Caching
ā¢ Logging
ā¢ Monitoring
ā¢ Business rules
ā¢ Code mobility
ā¢ Domain-specific optimizations
Issues of a Cross Cutting Concern
Owen Rubel owenr@uw.edu
15. Title Text
This is The API Patterns Brick Wall
Brick Wall
Owen Rubel owenr@uw.edu
16. Title Text
ā¢ APIās were created in 70ās to standardize information
exchanged between services
ā¢ 70ās api pattern was designed for centralized
architecture; distributed architectures didn't exist.
ā¢ Web APIās were based on 70ās api pattern; Roy Fielding
based his dissertation on this pre-existing pattern.
ā¢ Web APIās were integrated into MVC frameworks and
tools; it is now used everywhere.
Why Did This Happen? (1 of 2)
Owen Rubel owenr@uw.edu
17. Title Text
ā¢ Distributed Architectures are a New Pattern. Old principles
and patterns are often not re-examined unless an issue is
discovered. In the case of APIās, they are a tried and true
pattern and still work locallyā¦ but not ādistributedā
ā¢ People ASSUMED the resource was the endpoint; The
controller hands the resource OFF to the communication layer.
The communication layer hands off I/O to other services in a
distributed architecture. Hence, the communication layer is the
endpoint.
Why Did This Happen? (2 of 2)
Owen Rubel owenr@uw.edu
22. Title Text
This allows:
ā¢ Central Piece of architecture (where REQUEST AND RESPONSE
are handled) to be āSingle Version of Truthā (SOV) called āIO Stateā
ā¢ All services to sync data from SOV
ā¢ Failure of SOV DOES NOT affect synchronization of data
ā¢ Reload state on the fly at SOV and update ALL subscribed services
Shared IO State
Owen Rubel owenr@uw.edu
24. Title Text
What is IO State?
ā¢ Caches Communications Data
ā¢ Synchronizes Architectural Props (distribute rules of communication)
ā¢ Handles API Authorizations (access for communication)
ā¢ Api Docs Definitions (how to communicate)
I/O State is data directly related to a request/response, normally
separated from functionality. Handles all data associated with
communication and communication access
owenr@uw.eduOwen Rubel
25. Title Text
What Does IO State Contain
ā¢all the data contained in annotations act as rules associated with the
URI endpoint (not URL or the FQDN)
ā¢by containing all those rules in one file and caching that data, we can
share it with the other architectural components (and abstract data
from functionality)
ā¢this enables us to change it on the fly and reload without having to
restart any services allowing subscribed services to get changes
pushed to them through web hooks
owenr@uw.eduOwen Rubel
26. Title Text
I/O State : Communications Properties
Owen Rubel owenr@uw.edu
Shared I/O State is āIO Stateā data unbound from functionality
so that it can be shared across architectural components.
This is the approach used by distributed architectures.
Bound I/O State is āI/O Stateā data bound to functionality
which cannot be shared or synchronized with additional
architectural components creating an āarchitectural cross
cutting concernā. This is commonly found in centralized
architectures.
27. Title Text
Shared I/O State
Owen Rubel owenr@uw.edu
ā¢ DOESNāT bind to the application
ā¢ DOESNāT bind to functionality
ā¢ DOESNāT bind to a resource
28. Title Text
What Does It Look Like?
Title Text
Owen Rubel owenr@uw.edu
https://gist.github.com/orubel/7c4d0290c7b8896667a3
29. Title Text
Owen Rubel owenr@uw.edu
ā¢ Api Blueprint
ā¢ not role based
ā¢ confuses I/O state with content/resource
ā¢ duplicitous; lack of separation
ā¢ Swagger
ā¢ not role based
ā¢ based on annotations and thus not sharable in distributed architecture
ā¢ duplicitous; lack of separation
ā¢ redundant functionality for docs; does not make use of OPTIONS
ā¢ RAML
ā¢ not role based
ā¢ limited to CRUD-based REST of 4 calls per class
ā¢ duplicitous; lack of separation
30. Title Text
ā¢ Dramatic Code reduction By Reducing Duplication
ā¢ Automation of nearly all aspects of API
ā¢ Nearly 0% downtime for changes to endpoint data and rules
ā¢ New API Patterns (ie API Chaining (tm) )
What Does It Improve?
Owen Rubel owenr@uw.edu
31. Title Text
Code Reduction (1 of 2)
Controller : Mixed Concerns (Duplication)
@Secured(['ROLE_ADMIN', āROLE_USER'])
@RequestMapping(value="/create", method=RequestMethod.POST)
@ResponseBody
public ModelAndView createAddress(){
List authorities = springSecurityService.getPrincipal().getAuthorities()
User user
if(authorities.contains(āROLE_ADMINā)){
if(params.id){
user = User.get(params.id.toLong())
}else{
render(status:HttpServletResponse.SC_BAD_REQUEST)
}
}else if(authorities.contains(āROLE_USERā)){
user = User.get(principal.id)
}
Address address = new Address(params)
ā¦
address.user = user
ā¦
}
Owen Rubel owenr@uw.edu
32. Title Text
Code Reduction (2 of 2)
Controller : Single Concern
public ModelAndView createAddress(){
User user= (params.id)?User.get(params.id.toLong()): User.get(principal.id)
Address address = new Address(params)
address.user = user
ā¦
}
Owen Rubel owenr@uw.edu
The sad fact is that in todays development environment, engineers are still sadly under informed on micro services and distributed architectures. Even off the shelf tooling does not meet the needs of modern standards
Before I begin, Iād like to explain a few key principles that a few people might not be familiar with.
In a centralized architecture, we donāt have to share I/O
In a distributed architecture, shared I/O is REQUIRED!!!
Keep this picture in your mind: youāll notice the deployment pyramid is āflippedā; this shows how I/O is completely backwards now and how all previous development principles about I/O because they canāt be shared!
MQ: caching, queueing & postchecks on response data
Proxy: security & prechecks on request data
app server: core application, endpoints
If you are familiar with MVC, this can be considered SOC; objects/classes, config, services, database class, etc. all separate of concern/control
why donāt we mix? because we often have to share without sharing the other and a binding can create a difficulty or make it impossible without creating issues such as a ācross cutting concernā
in this case where I/O is not shared, this is perfectly acceptable because this is what is known as a ācentralized architectureā; I/O is not shared with other services.
Use āpickle jarā analogy
refer to slide 8
Abstract API data/function from Biz Logic to a āinterceptorā layer and add localized cache
(interceptors are also know as āfiltersā in Ruby and Python)
Abstract API data/function from Biz Logic to a āinterceptorā layer and add localized cache
(interceptors are also know as āfiltersā in Ruby and Python)
Use web hooks to get all services subscribed to API server so the can subscribe to CENTRALIZED cache and receive updates. This keeps all services in āsychedā state.
refer to slide 10
It is a properties file that can be cached by all parts of the architecture
It is a properties file that can be cached by all parts of the architecture
Youāll notice in this example the controller is doing ALOT of additional work:
role checking
request.method enforcement
uri mapping
input checking
A lot of I/O and security that has been tacked on; these are not part of its āseparation of concernā and need to be shared with the architectural components.
The controller is now a proper separation of concern and is STRICTLY focused on business logic