_This issue is a discussion and overview of possible strategies to serve pages dynamically._

Beacon needs to serve templates and data for each page that are created at runtime and there are different strategies with its own benefits and trade-offs. In order to compare such strategies, let's list the requirements first:

## Requirements

- Each page has an associated `template` and `assigns` where `template` is a string compiled to `Phoenix.LiveView.Rendered` and `assigns` is a map containing title, description, meta tags, and some other metadata.
- Publishing a new version of a page can't break the experience for current visitors, ie: if you have a open page you shouldn't be impacted.
- Deploying a site must not require more resources than available, ie: loading resources on the boot process should maintain memory and cpu limits within provisioned limits.
- Rendering pages should be as fast as possible.
- Recovering from a crash must handle all the reconnects.

Keep in mind such storage is dynamic as new pages are published it must be updated at runtime.

Below is a simplified pseudo-code of how templates and assigns are used in the LiveView that handle all requests:

```elixir
defmodule PageLive do
def mount(params, session, socket) do
page = load_page(site, path)
{:ok, assign(title: page.title)}
end

def render(assigns) do
page.template
end
end
```

Essentially the `PageLive` is a proxy that loads pages and serves the template and data on the regular LiveView workflow.

## Strategies

### Single Pages Module
One single module containing all templates and all assigns of all pages in this format:

```elixir
defmodule Pages do
def render("/" = _path) do
~H"

Home

"
end

def assigns("/" = _path) do
%{title: "Home"}
end

def render("/contact" = _path) do
~H"

Contact

"
end

def assigns("/contact" = _path) do
%{title: "Contact"}
end
end
```

#### Pros
- A single module to manage
- Pattern match on each function works as a router
- Slightly faster than multiple page modules

#### Cons
- Requires too much resource to load the module causing instability on every page update
- No isolation. If one page fails to compile the whole site is impacted and may suffer downtime
- We lose the ability to keep the old version of the module when it's recompiled (`:code.delete/1`)
- Simultaneous http requests or simultaneous page publishing may cause more than one compilation process to race each other causing the module being redefined multiple times

### Multiple Page Modules

_The current strategy in use._

```elixir
defmodule PageA do
def render do
~H"

Home

"
end

def assigns do
%{title: "Home"}
end
end

defmodule PageB do
def render do
~H"

Contact

"
end

def assigns do
%{title: "Contact"}
end
end
```

#### Pros
- Isolated. One page failure doesn't affect other pages and the overall site stability
- Replacing a module keeps the old version in memory for current processes so it's safer to update pages (individual `:code.delete/1` calls)

#### Cons
- Harder to manage multiple modules
- Requires a router ETS table to find the module to serve the page
- Simultaneous http requests (but not simultaneous page publishing) may cause more than one compilation process to race each other causing the module being redefined multiple times

### ETS
Essentially similar to multiple page modules but store pages into ETS, thus have essential the same pros and cons with the biggest difference that it's slower but handles concurrent requests more easily.

### Persistent Term
Very similar to ETS but should be a bit faster to read and much slower to write.

---

Performance is essential and can't be ignored. An [initial benchmark](https://dockyard.com/blog/2024/06/20/choosing-the-right-in-memory-storage-solution-part-2) shows that modules are faster than persistent_term and ETS.