Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Layered architecture Go API implementation

Layered architecture Go API implementation

Jumpei Takiyasu

April 25, 2018
Tweet

More Decks by Jumpei Takiyasu

Other Decks in Technology

Transcript

  1. = &Me{ Name: "Jumpei Takiyasu", Company: "M3, Inc.", Github: "juntaki",

    Twitter: "juntaki", Web: "https://juntaki.com", } recent := &Work{ "goo.glも終わるしGoとGAEで短縮URLサービスをつくろう", // https://s.juntaki.com/bAd "OK,Google Alexaに今日のニュースを聞いておいて", // https://s.juntaki.com/Q6T "Configurable Slack bot firestarterのつかいかた", // https://s.juntaki.com/sVd } About me
  2. juntaki/firestarter • Just-start bot • Simple web UI for configuration

    • Use in combination with various webhook such as IFTTT, Jenkins • Available for @everyone • Please try using this!! firestarter is made for simple working example of Layered architecture in Go. https://s.juntaki.com/sVd
  3. System-wide architecture firestarter(bot) Real Time Messaging Interactive messages firestarter(UI) config.json

    Internal API POST The internet Company Internal AWS Lambda Amazon SQS Amazon API Gateway
  4. firestarter(bot) Real Time Messaging Interactive messages firestarter(UI) config.json Internal API

    POST The internet AWS Lambda Amazon SQS Amazon API Gateway Architecture to be described Company Internal
  5. Overview - Layered architecture & Data Application What API user

    want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Data Layer API input / output (xml, json, protobuf, ...) Persistent storage format (DB schema, File format, ...) On memory structure Controller (IDL definition) Deserialized API input / output UI What end user want to do Translator Translator Are there too many layers?
  6. Dependency Layer Application What API user want to do Domain

    / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do The upper side of the figure is the High-level modules. There are more components in higher-level modules, which may change frequently. Flow of control Modules example
  7. Model-View-Controller like pattern point of view Layer Controller View Model

    MVC POV Modules should rely on the layer to less frequently change. High-level changes make just local impacts. However, If there is a change in the Low-level module, the impact propagates extensively. Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do Modules example
  8. Application What API user want to do Domain / Repository

    What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do Dependency inversion principle point of view Layer Logic Presentation Data DIP POV Abstructions Abstructions High-level modules should not depend on low-level modules. ...means, reducing dependence to modules with many dependencies. High-level changes affect low levels, but the propagation range of change is measurable. Modules example
  9. No silver bullet The way to implementation is depending on

    the purpose of software. • For speed at initial stage, MVC like arch. • For maintainability, DIP approach. You should consider some benefit of original module may be lost by excessive abstraction. (e.g. performance) Gopher may prefer robust DIP approach, layered architecture. • Easy to test by mocking • Interfaces implicitly decide each modules responsibility
  10. Dependency injection (DI) Layer DI is just strategy pattern. Modules

    to be injected is the source of inverted dependency. Where to inject it from? • DI container • main() • (or another choice) Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Controller (IDL definition) UI What end user want to do
  11. Directory structure Directory structure Layer Contents ├── admin UI Vue.js

    ├── proto Controller protocol buffers definition generated code (twitchtv/twirp) ├── application Application API Server impl ├── domain Domain Domain model Validator (go-playground/validator) Repository interface ├── infrastructure Infrastructure Repository impl: JSON serialization └── main.go - DI and load global settings Think framework (go-chi/chi) https://github.com/juntaki/firestarter
  12. DI at main() Inject Infrastructure dependency Inject Application dependency Application

    depends on domain Infrastructure implements domain’s interface https://github.com/juntaki/firestarter/blob/master/main.go
  13. Data translation Data API input / output (xml, json, protobuf,

    ...) Persistent storage format (DB schema, File format, ...) On memory structure Deserialized API input / output Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Translator Translator Translating is troublesome, but it is necessary for layer decoupling. The structure of each layer may be approximately the same at the initial stage. Generated code by protobuf Anticorruption, or..
  14. Stamp coupling, Data coupling? Command, Query? Persistent storage format (DB

    schema, File format, ...) On memory structure Deserialized API input / output Application What API user want to do Domain / Repository What business/software want to do Infrastructure How software is implemented Translator Translator Command / Query Instead of increasing complexity, it will be more robust architecture.
  15. Wrap up • Layered architecture is complex but robust design.

    • Data translation is important for layer decounpling. • No silver bullet Go API implementation is not easy but simple. It’s ideal for implementing complex architecture.
  16. References Challenge to Advanced API Architecture in Go by Seiji

    Takahashi https://speakerdeck.com/timakin/challenge-to-advanced-api-architecture-in-go GoにおけるDI http://inukirom.hatenablog.com/entry/di-in-go The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license.