Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

IO State In Distributed API Architecture

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 45 Anuncio

IO State In Distributed API Architecture

The API pattern bind IO functionality to business functionality by binding IO state either through annotation (ie JAX) or by extending a RestfulController. As a result, the data associated IO State cannot be shared with the architectural instances because it is bound to the controller. This creates architectural cross cutting concerns not only with the functionality but also with the data. By abstracting the functionality, we can create a versioned data object for IO state that can be shared,cached,synced,reloaded on the fly for all architectural instances without having to restart any instance. This greatly improve automation, performance and flow of api applications and architecture.

The API pattern bind IO functionality to business functionality by binding IO state either through annotation (ie JAX) or by extending a RestfulController. As a result, the data associated IO State cannot be shared with the architectural instances because it is bound to the controller. This creates architectural cross cutting concerns not only with the functionality but also with the data. By abstracting the functionality, we can create a versioned data object for IO state that can be shared,cached,synced,reloaded on the fly for all architectural instances without having to restart any instance. This greatly improve automation, performance and flow of api applications and architecture.

Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

Similares a IO State In Distributed API Architecture (20)

Anuncio

Más reciente (20)

IO State In Distributed API Architecture

  1. 1. SPRINGONE2GX WASHINGTON, DC Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attributio n-NonCommercial license: http://creativecommons.org/licenses/by -nc/3.0/ Shared I/O State in API Architecture By Owen Rubel @OwenRubel
  2. 2. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Owen Rubel • Original team member of Amazon 95-98 • Creator of API Chaining, API Abstraction and IO State • Grails API Toolkit • twitter: @owenrubel • linkedin: https://www.linkedin.com/in/orubel 2
  3. 3. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ First a Warning… 3
  4. 4. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Centralized vs Distributed Architecture • How many developers still use a centralized architecture vs a distributed architecture in their development? 4
  5. 5. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Centralized vs Distributed Architecture • 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? 5
  6. 6. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Centralized vs Distributed Architecture • 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? • Pattern existed since the 80’s(???) • 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 6
  7. 7. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ But What is The API Pattern? 7 “…specifies a software component in terms of its operations, their inputs and outputs and underlying types. Its main purpose is to define a set of functionalities that are independent of their respective implementation…”
  8. 8. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Thus an API is: • Separation of concern with a bound secondary concern • communication logic bound to business logic 8
  9. 9. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ And There Are Two Ways To Implement: • API As Software Pattern (Centralized Architecture) • API As Architectural Pattern (Distributed Architecture) 9
  10. 10. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ API as a Software Pattern (Centralized Architecture) 10 I/O RESOURCE MGMT REQUEST RESPONSE COMMUNICATION LOGIC CLIENT CLIENT CONTROLLER
  11. 11. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ API as an Architectural Pattern (Distributed Architecture) 11 I/O RESOURCE MGMT REQUEST RESPONSE HANDLER INTERCEPTOR PROXY MQ CONTROLLER REQUEST RESPONSE
  12. 12. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Sharing I/O Flow but NOT Sharing I/O Data 12
  13. 13. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ HANDLER INTERCEPTOR Mixed Implementation : Software Pattern in an Architectural Pattern (Part 1) 13 REQUEST COMMUNICATION LOGIC PROXY MQ CONTROLLER RESPONSE RestfulController, @RequestMapping, @RequestParam, @ResponseBody, @PathVariable I/O RESOURCE MGMT
  14. 14. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Mixed Patterns: Issues? • Duplicate Code • Duplicate Handling of Flow • Software Confusion • Architectural Confusion • Cross Cutting Concerns • Inability to share I/O state with services that share I/O flow 14
  15. 15. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Mixed Implementation: Duplicitous Code (Part 2) 15 @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 … }
  16. 16. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Mixed Implementation :Manually Coding of Flow (Part 3) 16 REQUEST COMMUNICATION LOGIC PROXY MQ CONTROLLER RESPONSE Automated flow PRE POST Manually Encoded flow per method HANDLER INTERCEPTOR
  17. 17. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Mixed Implementation :Dropped Threads (Part 3) 17 REQUEST COMMUNICATION LOGIC PROXY w/ Security MQ CONTROLLER RESPONSEPRE POST HANDLER INTERCEPTOR Dropped Thread and IO bound REDIRECT
  18. 18. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ “This Fixes Everything That We Are Currently Having Issues With!” 18 - API Manager, Netflix
  19. 19. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Mixed Architecture: Inability to Share Data w/ Architecture (Part 4) 19 HANDLER INTERCEPTO R REQUES T COMMUNICATION LOGIC PROX Y MQ CONTROLLE R RESPONS E post/show/1 {GET,JSON, ROLE_ADMIN } {…} RestfulController, @RequestMapping, @RequestParam, @ResponseBody, @PathVariable ???
  20. 20. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ The API Pattern is Either Application OR Architecture… But Not Both! 20
  21. 21. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Benefits of an API as Architecture? • Easier to abstract components • Once components abstracted, easier to share with services using IO flow • Can separate data from functionality • Check security early and late in proxy and MQ; can also check security in handlerInterceptor on redirect/forward. • More Scalable… both Vertically and Horizontally due to better separation. • Made for Automation (Batching, api chaining, api doc generation based on roles, etc) • Api Multi-tenancy (functionality can be split, combined, joined without application rewrite) • Vast reduction in code required; no duplication in controllers. • Shared IO State for sharing with IO flow 21
  22. 22. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ So How Do We Solve? 22
  23. 23. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Web API (as the Application) : Shared Architecture 23 REQUEST RESPONSE HANDLER INTERCEPTOR PROXY MQ CONTROLLER I/O RESOURCE MGMT
  24. 24. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ So How Do We Share the Data Across the Architecture? 24
  25. 25. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Cached I/O State in Architecture 25 REQUEST HANDLER INTERCEPTOR PROXY MQ CONTROLLER CACHE (I/O STATE) SUB/PUB RESPONSE SUB/PUB
  26. 26. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ So What is I/O State? 26
  27. 27. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ I/O State : Communications Rules 27 I/O State is data directly related to a request/response, normally separated from functionality. Handles all data associated with communication and communication access • Caches Communications Data • Synchronizes Architectural Properties • Handles API Authorizations • Api Docs Definitions
  28. 28. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ I/O State 28 • all the data contained in annotations act as rules associated with the uri endpoint • by containing all those rules in one file and caching that data, we can share it with the other architectural components • this enables us to change it on the fly and reload without having to restart any services and subscribed services will have changes published to them through web hooks
  29. 29. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ I/O State : A Cached Communications Property File 29 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.
  30. 30. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Shared I/O State • DOESN’T bind to the application • DOESN’T bind to functionality • DOESN’T bind to a resource 30
  31. 31. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ What Does It Look Like? 31 https://gist.github.com/orubel/7c4d0290c7b8896667a3
  32. 32. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ What Shared I/O State Maintains… 32 • Values provided for Input/Output • All Endpoints • Endpoint Authorization (ie Roles) • Endpoint Request Method (GET, PUT, POST, DELETE) • Expected Input per Endpoint • Expected Output per Endpoint • Version for document • Deprecation Date for document • Batching Authorization (and toggle) • and more
  33. 33. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Similar technologies (and How They Compare) • Api Blueprint • confuses I/O state with delivery content (which doesn’t need to be shared) • duplicitous; lack of separation • no roles • Swagger • not role based • based on annotations and thus not sharable in distributed architecture • only focused on API docs • duplicitous; lack of separation • RAML • not role based • limited to ‘traditional’ REST of 4 calls per class • duplicitous; lack of separation 33
  34. 34. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Controller : Mixed Concerns (Duplication) 34 @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 … }
  35. 35. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Controller : Mixed Concerns (Duplication) 35 @RequestMapping(value="/create", method=RequestMethod.POST) @ResponseBody public ModelAndView createAddress(){ User user= (params.id)?User.get(params.id.toLong()): User.get(principal.id) Address address = new Address(params) address.user = user … }
  36. 36. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Controller : Single Concern 36 public ModelAndView createAddress(){ User user= (params.id)?User.get(params.id.toLong()): User.get(principal.id) Address address = new Address(params) address.user = user … }
  37. 37. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Ok But How Does it Work W/O Annotations? 37
  38. 38. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Bootstrap : Load Data into Cache 38 class ApiBootStrap { def apiObjectService def init = { servletContext -> apiObjectService.initialize() } def destroy = {} }
  39. 39. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Url Mapping : Map Endpoints 39 static mappings = { String apiVersion = getGrailsApplication().metadata['info.app.version'] String api = "v${apiVersion}" // REGULAR API ENDPOINTS "/$api/$controller/$action?/$id?(.$format)?"{ parseRequest = true } "/$api/$controller/$action/$id**" { parseRequest = true }
  40. 40. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ HandlerInterceptor: Run checks on Requests Against Cache 40 boolean before(){ LinkedHashMap cache = (params.controller)?apiCacheService.getApiCache(params.controller):[:] if(cache){ boolean result = apiRequestService.handleApiRequest(cache,request,params) return result} return false } boolean after(){ Map newModel = (model)?apiResponseService.convertModel(model):model Map cache = (params.controller)?apiCacheService.getApiCache(params.controller):[:] Map content = apiResponseService.handleApiResponse(cache,request,response,newModel,params) if(content){ render(text:content.apiToolkitContent, contentType:"${content.apiToolkitType}", encoding:content.apiToolkitEncoding) return false} return false }
  41. 41. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Flow 41 PREHANDLER REQUESTSERVICE POSTHANDLER RESPONSESERVICECONTROLLER request response after() controller/action handleApiRequest handleApiResponse model, headers, etc true/falsefalse true
  42. 42. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ To Create Something Like This… 42 https://gist.github.com/orubel/d5b161332b5a788828eb
  43. 43. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Demo 43
  44. 44. Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attribution-NonCommercial license: http://creativecommons.org/licenses/by-nc/3.0/ Questions? 44
  45. 45. SPRINGONE2GX WASHINGTON, DC Unless otherwise indicated, these slides are © 2013 -2015 Pivotal Software, Inc. and licensed under a Creative Commons Attributio n-NonCommercial license: http://creativecommons.org/licenses/by -nc/3.0/ • API Chaining and API Abstraction (http://www.slideshare.net/bobdobbes/api- abstraction-api-chaining) • The API is Dead, Long Live The API (http://www.dev9.com/article/2015/9/api-is- dead) • Why the API Pattern is Broken and How We Can Fix It (http://apievangelist.com/2015/05/05/guest-post-why-the-api-pattern-is-broken- and-how-we-can-fix-it/) Additional Links

Notas del editor

  • work on title
    perhaps something less intimidating; more relatable to work they are doing without ‘fancy names’
  • What I am about to show you will:
    amaze
    anger
    shock
    annoy
    astound
    and confuse
    can be controversial

    May not get it immediately. Those that do will walk out of here looking at api development with new eyes… thats a promise. You will never see them the same way again.

    I’m going to tell you right now that this is a rethinking of the api pattern and a lot of its premises in how it is implemented so if you are not ready for a bumpy ride or if you have a weak heart, I’ll give you a moment to step outside…

    … ok and with that…
  • let me ask you this…
  • the reason I bring this up…
    This number used to be around 50% in 2005. Now, it’s roughly 25-30% now… and going down.
    the api pattern was originally designed for software applications (centralized architecture)
  • but what is an api?
    In Short: An API is a separation of concern of I/O for functionality of resource management
  • - For example…
  • Now the most common way is…api as software pattern
    This is ONE software application… or a piece of software contained within ONE software application (creating a centralized architecture).

    Here concerns are separated

    standardized input/output to a separation of concern within the application
    the separation of concern binds communication logic to a service which does resource mngmt (ie the resource that is requested, manipulated and returned)

    api as architectural pattern is api as service amongst multiple connected software services (creating a distributed architecture).

    The api pattern for architecture is IDENTICAL except the separation of concern is a software component separated from other software components… not concerns separated from other concerns.

    In a distributed architecture, we can see:
    there is already I/O and resource management in the standard MVC application
    with request/response coming/going to other architectural components

    … everything is mapped.

    This is STILL a centralized architecture at this point but has the POTENTIAL to be more easily become a DISTRIBUTED architecture

    Unfortunately, we didn’t understand that api is architecture as well as software and so when applying it to the web, we applied the the software pattern rather than the architectural pattern
  • For as you see when we add other services, we can share the I/O flow.

    But now we have a problem…
  • Current implementations in distributed architectures are not so NEAT.
  • This creates a mixed implementation.

    creating massive redundancy and duplication with every method.
  • Software confusion: where do we handle batch jobs? Where do we do checking? how do we handle loopback and redirect?
    Architectural confusion: how do we share with external services? What do we share? How do we keep things in sync across architectural components and api instance?
  • We literally have to duplicate this information with EVERY method
    then , as you can see in the body, we have to do additional checks for multiple roles handling this.
    This can’t be separated and moved to the PROXY without duplicating or entanglement making it impossible to synchronize this data.
    Thus overtime this data changes, it requires ‘human intervention’ to make sure ever instance of it remains synchronized due to this ‘hard coding’.

  • having to manually code the flow creates massive code duplication
    it also makes it so you have to shut down the server and bring it back up overtime you want to add something new to the flow
    by using existing communication layer, this reduces duplication and allows you to merely uses properties as toggles
    finally, flow cannot be easily isolated and moved to separate server without creating entirely separate project; as separate layer, can be detected at proxy and sent to separate server to have separate functionality handled so as to not affect unaffected processes.
    example: api batching

  • having to manually code the flow creates massive code duplication
    it also makes it so you have to shut down the server and bring it back up overtime you want to add something new to the flow
    by using existing communication layer, this reduces duplication and allows you to merely uses properties as toggles
    finally, flow cannot be easily isolated and moved to separate server without creating entirely separate project; as separate layer, can be detected at proxy and sent to separate server to have separate functionality handled so as to not affect unaffected processes.
    example: api batching
  • When I showed this to Netflix and how their tools like Zuul were doing precisely this, this is how the api manager responded.

    And that not all…

  • Data stored/used in annotations cannot be shared with architectural components without duplication.

    Annotations cant be cached as they would exist in two places: the controllers and the cache; this data would be impossible to sychronize. This is what is known as an architectural cross cutting concern as it creates duplication and/or entanglement.

    Thus at this point we can easily state…
  • These two concepts cannot be reconciled without created a cross cutting concern every time.

    Mixing the two causes api as an architectural pattern to DEFAULT to being an api as a software pattern and thus a centralized architecture.

    The modern web api is a mixture of these two and as such has issues in scaling in distributed architectures as a result of creating this architectural cross cutting concern.

    The solution is to apply the api pattern as architecture and not as software. Only then can you resolve issue with architectural components as you scale your application.
  • we need to see api as separation of SERVICE rather than separation of concern
    we don’t need to add anything here as all the necessary structure is already in place
    we just need to code our logic in correct places (communication logic in handler interceptor and business logic in controllers)
  • By preloading the IO state at runtime, we can:
    share with all subscribed services to the api through a pub/sub model via web hooks

    all the data contained in annotations act as rules associated with the uri endpoint
    by containing all those rules in one file and caching that data, we can share it with the other architectural components
    then we can change and it on the fly and reload without having to restart any components and subscribed services will have changes published to them through web hooks

  • no its not a college in the midwest
  • There are two types of IO state…

    What does it do?
  • It is a complete separation
  • well in Grails, without giving away too much of the secret sauce right now, I did it in the handler interceptor like this…
  • 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
  • At runtime, we bootstrap the files so that are loaded and cached…
  • Then in urlmapping, we create a default mapping based on app version to handle all mappings…
  • The controller is now a proper separation of concern and is STRICTLY focused on business logic
  • The controller is now a proper separation of concern and is STRICTLY focused on business logic

×