# `NebulaAPI.Server`
[🔗](https://github.com/podCloud/nebula_api/blob/v0.7.1/lib/nebula_api/server.ex#L1)

Per-application supervisor for NebulaAPI workers.

One `NebulaAPI.Server` lives in the supervision tree of each OTP application that
owns modules using `NebulaAPI` (wire it in with `use NebulaAPI.Server` +
`nebula_api_server/0`). It is given `app_module:` — a module belonging to that app — from
which it resolves the owning app, lists *its* modules, and keeps only those that:

  1. carry the persisted `:nebula_api` marker (i.e. they `use NebulaAPI`), and
  2. have at least one method compiled as **local** on this node,

and starts one `NebulaAPI.APIServer.Worker` per retained module. Each worker joins
the cluster-wide `:pg` group so remote nodes can route to it.

Living inside the app's own tree is what makes the lifecycle correct: when the app
stops or crashes, this supervisor (and its workers) go down with it and `:pg` drops
the entries. The serving set is discovered from the app's compiled modules.

# `__using__`
*macro* 

Brings the `nebula_api_server/0` macro into scope, plus the `NebulaAPI.AST` macros
(`on_nebula_nodes`, `call_on_*`). For the host module — typically the app's
`Application` — that wires the per-app server into its supervision tree.

Unlike `use NebulaAPI`, this does **not** register the `defapi` bookkeeping
(`:nebula_configured_nodes`, the `:nebula_api` marker) nor validate `self_node` — the host
module has no `defapi` of its own, so none of that applies. Use `use NebulaAPI` only on
modules that actually define `defapi` endpoints.

# `child_spec`

Returns a specification to start this module under a supervisor.

See `Supervisor`.

# `nebula_api_server`
*macro* 

Expands to a child spec for `NebulaAPI.Server`, to be placed in the supervision tree of
an OTP application that owns modules using `NebulaAPI`.

Brought into scope by `use NebulaAPI.Server`. It expands at the call site, so
`__MODULE__` is the host module (typically the app's `Application`), which belongs to
the consumer's OTP app — all the server needs to resolve the app and, at runtime,
discover its modules, keep the ones with local methods on this node, and start a worker
for each. Because the server lives inside the app's own tree, the worker lifecycle is
correct for free: app stops or crashes → server and workers die with it, `:pg` drops
the entries.

    defmodule MyApp.Application do
      use Application
      use NebulaAPI.Server

      def start(_type, _args) do
        Supervisor.start_link([nebula_api_server()], strategy: :one_for_one, name: MyApp.Sup)
      end
    end

# `print_routes`

Print the per-node routing map (local vs remote per node) from a running node — e.g. in iex:

    iex> NebulaAPI.Server.print_routes()

Delegates to `NebulaAPI.Routes.print/1`; see it for options (`:color`, `:nodes`, …).

# `start_link`

---

*Consult [api-reference.md](api-reference.md) for complete listing*