Slide 1

Slide 1 text

Zdeněk Němec, superface.ai, October '22 APIs in N-tier architecture The role of APIs in modern enterprise applications

Slide 2

Slide 2 text

Founder & CTO of Superface.ai • Pioneered the API- fi rst approach at Apiary.io → Oracle • Founder of API consulting Good API • Helped several Fortune 100 companies with their API strategy and execution
 • Founder and CTO of Superface.ai Zdeněk “Z” Němec superface.ai

Slide 3

Slide 3 text

APIs are connecting the world superface.ai

Slide 4

Slide 4 text

Business capabilities Technical 
 interfaces APIs APIs are where business capabilities meet technical interfaces Business + Engineering superface.ai

Slide 5

Slide 5 text

APIs are hefty burden Accelerated by global pandemic, the need for API integrations grew in 80,4% of companies 700 days Average time needed by a SaaS app to build API integrations Top SaaS apps have 7000+ integrations $200.000 / year Cost of building and running one public API Providing high quality APIs needs deep expertise & dedication > 50% dev effort Developers are spending more time with APIs 49% of 28.252 Postman respondents said that more than half of the organization’s development e ff ort is spent on API superface.ai

Slide 6

Slide 6 text

Challenges with APIs • Business and organizational alignment • API documentation • Poorly maintained API catalogs • API-design • Too many microservices • Securing API, obtaining access • Developer onboarding, hiring, and attrition API as deployed API as consumed API as documented NOTE: Some of these challenges are covered by Abhinav Asthana in https://blog.postman.com/2022-api-platform- landscape-trends-and-challenges superface.ai

Slide 7

Slide 7 text

APIs in Enterprise Architecture Role of an architect Architect knows something about everything. Engineer knows everything about one thing. Understand many paradigms and patterns. Pick the right one for the task based on the constraints. superface.ai

Slide 8

Slide 8 text

Follow your constraints Decide on architecture based on your constraints and business needs “I really like colonial houses, I think I’ll build one…” Houses were colonial because of the colonists were colonial and had colonial constraints “I really like REST (GraphQL) APIs, I think I’ll build one…”

Slide 9

Slide 9 text

Constraints and induced properties API patterns: REST, GraphQL, Kafka, RPC, Flat fi le… Decoupled Evolvable + Stateless Reliable Scaleable + + Degraded ef fi ciency - Uniform
 Interface Simplicity +

Slide 10

Slide 10 text

API Strategy & the role of APIs superface.ai

Slide 11

Slide 11 text

Drivers for API E ffi

Slide 12

Slide 12 text

Role of APIs In the API Strategy • APIs acknowledged and managed as a possible direct source of monetization (API as a product) API as a Product • APIs acknowledged and managed as an essential strategic foundation for creating new value chains and products (product as API) API as the Enterprise Applications Enabler superface.ai

Slide 13

Slide 13 text

Layering Concept superface.ai

Slide 14

Slide 14 text

Layering Breaking apart a complicated system • Subsystems arranged in a layer cake • Higher layer use the lower layer • …but not the layers below (encapsulation) • Lower layers are unaware of the higher layers superface.ai

Slide 15

Slide 15 text

Isolation & Abstraction Dealing with the complexity • Programming language • Operating system • Device drivers • CPU instructions • Logic gates • HTTP • TCP • IP • Ethernet Programming Network communication superface.ai

Slide 16

Slide 16 text

Benefits & Downsides of Layering • Bounded (limited) understanding • Standardization • Replacement of layers • Reusability • Minimal dependencies • Cascading changes • Performance impact • Complexity of the entire application • Time-to-delivery • Isolation of the layer’s responsibility Pros Cons superface.ai

Slide 17

Slide 17 text

Principal layers superface.ai

Slide 18

Slide 18 text

Three Principal Layers of Enterprise Application Architecture Presentation Presentation UI, Voice, CLI, API, … Domain Domain Business logic, calculation, validation, routing Data Data source Hidden completely from the presentation superface.ai

Slide 19

Slide 19 text

Hexagonal architecture Symmetrical view • Similarity of the presentation and data source layers • Presentation & data are just connections to the outside world • Core surrounded by interfaces to external systems • Everything is an outside interface (symmetrical) https://net fl ixtechblog.com/ready-for-changes-with- hexagonal-architecture-b315ec967749 superface.ai

Slide 20

Slide 20 text

Architectural patterns Patterns of Enterprise Application Architecture • Domain logic patterns • Data source patterns • Object-relational patterns • Behavioral, Structural, Metadata- mapping, … • Web presentation patterns • MVC, Front controller, template p… • Distribution • Concurrency & session state superface.ai “An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.” • Layered pattern • Client-server • Broker • Interpreter • Master-slave • Pipe- fi lter • Peer-to-peer • Event bus …

Slide 21

Slide 21 text

Layers in a Enterprise Applications Cake or Cupcake? Monolith Horizontal teams Modular monolith, microservices Vertical, full-stack, end-to-end teams https://martinfowler.com/bliki/PresentationDomainDataLayering.html superface.ai

Slide 22

Slide 22 text

The API Layer superface.ai

Slide 23

Slide 23 text

API as Presentation layer • API is a top presentation layer delivering business capabilities • Drivers: direct monetization, added value, partner channels • API as a Product • API- fi rst API as a Product Domain API (Presentation) Data superface.ai

Slide 24

Slide 24 text

API as interface between layers • Provide means of communication between layers • Drive revenue-generation, innovation, e ffi ciency • API is interface to a higher layer • Database API, Headless CMS, etc. API as an enabler of Enterprise Application Domain Presentation Data API superface.ai API

Slide 25

Slide 25 text

Service Layer Pattern • Domain logic split in two sub-layers • Service / Domain model • Clear API, abstraction over domain logic • Transaction control and security • Federation • How much behavior to put in it? • API is not a domain (business) layer • Avoid the fallacy of ESB! • single point of failure • domain logic in what should have been a service layer Domain model Service layer (API) Domain
 layer Presentation Data superface.ai

Slide 26

Slide 26 text

Treat every API as a public API presentation layer. superface.ai

Slide 27

Slide 27 text

API Landscapes superface.ai

Slide 28

Slide 28 text

Organizational API landscape Multiple enterprise applications superface.ai

Slide 29

Slide 29 text

Multiple landscapes APIs landscapes are not isolated Stripe Azure Ayden Twilio Google Fedex … Global Landscape Global capabilities available within ACME Corp Partner Corp Service 2 Service 1 Service 3 Enterprise application CRM Inventory 2 Orders Inventory 1 PLM ACME Corp Partner Corps’ capabilities superface.ai

Slide 30

Slide 30 text

Presentation layer as a Data layer Hexagonal view Domain Frontend CLI API Data Order application Domain API Data Inventory service Data layer to the order application superface.ai

Slide 31

Slide 31 text

Domain model superface.ai

Slide 32

Slide 32 text

goodapi.co Canonical data model is anti-pattern superface.ai For “end-to-end” apps (modular monolith, microservices)

Slide 33

Slide 33 text

Domain-driven Design Divide and conquer complexity by bounded context and context mapping Domain-driven design distilled • Bounded context Boundary within a domain where a particular domain model applies • Set of functional features (user stories / use cases) • A term can have di ff erent meaning within di ff erent context superface.ai

Slide 34

Slide 34 text

API maps the Context Layer as a boundary • Layer can (but doesn’t have to) be a boundary • Context separation might be on the level of end-to-end modules or microservices superface.ai

Slide 35

Slide 35 text

API Representor pattern Anticorruption layer (ACL) • Mapping between your domain and other bounded context / 3rd party dependencies • Shield your layer from cascading changes • Integrate heterogenous systems within an enterprise • ESB served this purpose Domain API representor (adapter) superface.ai

Slide 36

Slide 36 text

REST Representational state transfer • Manipulation of resources through their representations • REST API server exposes representation of resources over a message format (content-type) • Client then uses representor pattern to map API’s representation to its own domain model superface.ai Domain Domain API Data representor representor representations

Slide 37

Slide 37 text

Key takeaways • Layering to manage complexity, promote reusability, minimize dependencies • Three fundamental layers: presentation, domain, data • Hexagonal architecture is a symmetrical view of principal layers • Split large layers vertically with modular monolith or microservies • API is a presentation (service) layer, avoid domain logic in it • Presentation layer might be a data layer to another app • Divide domain model into context, map context in APIs with representor pattern superface.ai

Slide 38

Slide 38 text

Questions? superface.ai 5 books for fi rst 5 questions

Slide 39

Slide 39 text

Thank you! Let’s talk! Superface.ai – the open source framework for Autonomous APIs https://github.com/superfaceai Zdenek “Z” Nemec 
 Twitter: @zdne superface.ai superface.ai