[DRAFT] Add a new Distribution case known as Application

[DamianReeves]

[DRAFT] Adding Application as A New Distribution Kind

Note this proposal is intended to supersede the proposal for adding Bundle as a distribution.

Overview

Programming languages have a history of partitioning the kinds of artifacts/distributions produced by their tooling/compilers into one of two categories: libraries or applications.

• Libraries - code that is meant to be shared and reused in order to build applications
• Applications - a set of packages/modules/code meant to be directly executable or executable within some given runtime environment.

Elm, .NET, Go, Rust, and C/C++ are all examples of programming languages which have this distinction.

It has become increasingly apparent that the Morphir community (its current and potential adopters) have use-cases that would benefit from the addition of a new application focused distribution.

What are some of the capabilities and properties that an Application distribution should have, and what use-cases should it enable.

• Should support one or more "entry points"
• Should support metadata that allows Morphir tooling to generate or bind to a variety of backends and runtimes/ execution environments.
• Should serve as a standalone distribution of all types and functions used by the application

NOTE: It is possible applications here can also be synonymous with services, where services are some runtime hosting/executing Morphir applications.

Applications Have Entry points

In programming languages applications have entry points. And the same should hold for Morphir Applications. A Morphir Application distribution should capture enough context that a backend or runtime of some sort can interrogate/analyze/scan a Morphir distribution and know what are the possible entry points.

It may be possible that there are multiple entry points within one application and that that entry point is meant to enable a specific service.

Below is one possible view:

Entry Point Selection

import Morphir.Graph.Grapher exposing (Graph)

{-| Represents a service which is an area or piece of executable functionality
provided by an application
-}
type alias ServiceName = Path

{-| Uses Graph (or a structure like Graph) to provide extensible metadata -}
type alias EntryPointMetadata = Graph

{-| Represents a single EntryPoint given its name and metadata -}
type EntryPoint = EntryPoint FQName EntryPointMetadata

{-| A collection of -}
type alias EntryPoints = List EntyPoint

type alias PackageDef = Package.Definition Graph

type alias EntryPointSelector = PackageDef -> EntryPointMetadata -> EntryPoints

type alias EntryPointConvention =
   { selector: EntryPointSelector
   , metadata: EntryPointMetadata 
   }

type EntryPointSelector 
   = Static (Dict ServiceName EntryPoints)
   | Dynamic (Dict ServiceName EntryPointConvention)

Applications Should Support Metadata To Help With Binding To A Variety Of Backends/Runtimes

Applications Are Standalone

The Application distribution should represent a fully standalone unit, this should include not just user defined functions but also potentially what SDK and Native functions/types are used.

Why would we want this?

Use-case A
One use-case that we have is to fully version a Distribution and to be able to make claims that:

• Two Application distributions are equivalent
  • Where equivalence is roughly defined as equal definitions where the concept of "equals" for native things is a tad bit looser
• Two Application distributions are compatible -
  • Where compatibility can be evaluated strictly by signatures.

To be more concrete, our use-case requires us to be able to safely version the types and logic we would be embedding in an application. By contract our use-case wants to ensure when replay events or messages and execute those events/messages against the "Application" that we are guaranteed the "Application" is consistent. This consistency guarantee may be relaxed to allow for compatible bug fixes.

Use-case B
An additional (and unrelated use-case) is to allow for tree-shaking of a distribution all the way down to what portion of the Morphir.SDK needs to be exposed. This can be crucial in reducing the size of the Application, as well as allowing for code-generators to only generate the required portion of the Morphir.SDK.

Possible Approaches

Include the Package Specification for the SDK as part of the signature

type Distribution
    = Library PackageName (Dict PackageName Package.Specification) Package.Definition
    | Application PackageName (Dict PackageName Package.Definition) Package.Definition Package.Specification

type alias ApplicationDistribution =
   { name: PackageName
   , dependencies: Dict PackageName Package.Definition
   , definition: Package.Definition
   , referencedSdkSpecification: Package.Specification
   }

Pros

1. With this approach we should have enough information to support the tree-shaking use-case (B) but we cannot support the strictest version of use-case A.

Cons

1. This option would allow us to mostly meet the needs of the use-case above but it does not allow us to embed implementations of SDK functions which are not natively implemented: i.e. things like Morphir.SDK.Rule, much if not all of Morphir.IR, and others.

Introduce DependencyDefinition to provide finer grained dependency information

We could introduce a type that allows us to classify a dependency as being one of the following:

• Builtin - The package is built-in to the application (no further details are given so anything in that package is considered to be built in... unfortunately there is no meaningful way of querying package membership apart from the PackageName
• Embedded - The package definition will be embedded in the Application

{-|
   BuiltIn - The package is built in and exposes the defined set of specifications
   Embedded - The Package Definition is embedded in the application
   External - The package is externally implemented and exposes the provide specification  
-}
type DependencyDefinition
= BuiltIn
| Embedded Package.Definition
| External Package.Specification

intrinsicSdkPackageDef: PackageDefinition
intrinsicSdkPackageDef = 
  let
     packageName = Path.fromString "Morphir.Sdk"
  in
     Intrinsic packageName

type Distribution
    = Library PackageName (Dict PackageName DependencyDefinition) Package.Definition
    | Application ApplicationDistribution

type alias ApplicationDistribution =
   { name: PackageName
   , dependencies: Dict PackageName Package.Definition
   , definition: Package.Definition
   , referencedSdkSpecification: Package.Specification
   }

[AttilaMihaly]

Thank you for the detailed proposal. There's a lot of good ideas here. I'm wondering if it would make sense to separate out the core bundling aspect of the proposal from the other aspects such as entry points, metadata, SDK inclusion? That way we could start by introducing the Application type and refine the details later.

I'm not sure but it seems like you forgot to include the ApplicationDistribution type in the Distribution in your examples. Or was that intentional? I was expecting something like this:

type Distribution
    = Library ...
    | Application ApplicationDistribution

type alias ApplicationDistribution = ...

[DamianReeves]

Yes I'll break this up into separate proposals.

[DamianReeves]

Also updated the example to use ApplicationDistribution