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

Adventures in Umbrella App Design

Desmond Bowe
September 29, 2017

Adventures in Umbrella App Design

An Experience Report on wacky things I've tried when building Umbrella projects.

Desmond Bowe

September 29, 2017
Tweet

More Decks by Desmond Bowe

Other Decks in Programming

Transcript

  1. ☂ "Umbrella projects are used to build applications that run

    together in a single repository.” - elixirlang.org
  2. ☂ my_app/ _build/ config/ deps/ lib/ my_app/ my_app.ex log/ priv/

    test/ mix.exs mix.lock _build/ apps/ my_app/ config/ deps/ lib/ my_app/ my_app.ex log/ priv/ test/ mix.exs mix.lock photo_service/ config/ deps/ mix.exs mix.lock Normal App Umbrella App
  3. Example 1: Twig Infrastructure • landing site • admin site

    • backoffice Needs • share assets across web frontends • web frontends need data from different services
  4. Twig 1st approach • 3 phoenix applications • separate assets

    app apps/ admin/ assets/ landing/ mother_brain/
  5. Twig • share js, css, images • assets app is

    styleguide • hard to share templates • redundant dependencies • painful upgrades
  6. Twig 2nd approach • all web apps in single OTP

    app apps/ mother_brain/ site/ config/ web/ admin/ assets/ landing/ controllers/ views/ endpoint.ex router.ex web.ex
  7. Twig • share js, css, images • assets app is

    styleguide • easy to share templates • streamlined dependencies • simpler authentication • configuration • file organization is important to reduce cognitive load
  8. Example 2: Crevalle Infrastructure • many distinct user-facing apps with

    individual datastore Needs • easily spin up new projects • reuse functionality • bird’s eye view of company
  9. Crevalle Approach • each project is its own app •

    shared functionality (e.g. image processing, authentication) is extracted to its own app apps/ chitta/ crux/ oauth/ postfactor/ pulse/ config/ lib/ web/
  10. Crevalle if your entire company is an umbrella app, your

    company’s individual services are their own OTP apps • teams work on specific app • apps are individually deployed to appropriate hardware • monolith + services • no more issues of internal API versions, data serialization
  11. Rules of Thumb for OTP apps • it has its

    own datastore • it has particular resource needs (eg high CPU load) • shared functionality
  12. successful Elixir application design means thinking in terms of Applications

    we are still figuring this out. join us at the bar!