Reactor

[nelsonic]

mentioned by @ndrean in #163 and #159 (comment) 💬

https://github.com/ash-project/reactor

"Reactor is a dynamic, concurrent, dependency resolving saga orchestrator."

• Saga orchestrator A saga is a way of providing
  transaction-like semantics across multiple distinct resources.
• Dependency resolving reactor allows you to describe the dependencies
  between your saga steps using arguments which are converted into a
  [DAG][dag] and used to compute execution order.
• Concurrent unless otherwise specified reactor will run as many steps as
  possible concurrently whilst taking into account the results of the dependency
  resolution.
• Dynamic whilst you can define a reactor statically using our awesome DSL,
  you can also build workflows dynamically - and even add steps while the
  reactor is running.

Getting started: https://github.com/ash-project/reactor/blob/main/documentation/tutorials/01-getting-started.md

[ndrean]

@nelsonic

Quick question: do you find yourself researching through all your repos? researching through all issues in your repos?

I was thinking of an MCP server based on your repos/issues, and a basic interface and a simple AI-assisted interface ((for natural language dialogue) using a very cheap Mistral API "ministral-small" (https://mistral.ai/pricing/api/)

Cost: $0.10 | $0.10, per million token
An input could be 10k token, so 100 queries is 0.10. Cheap.

GitHub supports semantic search :

# Full-text search issues in a specific repo
gh api search/issues -X GET -f q="repo:dwyl/auth authentication login"

# Semantic search (finds conceptually related results, not just keyword matches)
gh api search/issues -X GET -f q="repo:dwyl/auth how to handle sessions" -f search_type=semantic

# Hybrid (keyword + semantic combined)
gh api search/issues -X GET -f q="repo:dwyl/auth authentication" -f search_type=hybrid

# Search code in a repo
gh api search/code -X GET -f q="repo:dwyl/auth defmodule"

Aproject architecture could be:

  User: "find how dwyl handles authentication"
    │
    ├─ MCP tool 1: search_repos(org, query)
    │   → GitHub API: /search/repositories?q=org:dwyl+authentication
    │   → returns: dwyl/auth, dwyl/auth_plug, dwyl/phoenix-auth-example
    │
    ├─ MCP tool 2: search_issues(repo, query)
    │   → GitHub API: /search/issues?q=repo:dwyl/auth+authentication&search_type=hybrid
    │   → returns: top N issues with title + body snippet
    │
    └─ LLM synthesizes the answer from tool results

GitHub already does semantic matching on their side. Then MCP server would just be a thin wrapper around gh api search/* with the repo: qualifier.

=> 3 MCP tools (search_repos, search_issues, search_code), no database, no cron, no embeddings. Just GitHub API calls + authentication.

MCP libraries: https://hex.pm/packages/ex_mcp or https://hex.pm/packages/hermes_mcp

Sources:

• REST API endpoints for search - GitHub Docs
• Improved search for GitHub Issues (semantic/hybrid)
• API support for advanced search

[nelsonic]

@ndrean sounds like a fun project.
Only question is: how easy is it for the person using the interface to abuse it?

[ndrean]

@nelsonic Without even talking about obvious rate limiting, what do you mean by abuse? because you are essentially hitting the read-only Github API of limited scope public repos. The AI is a classifier with no execution capability and uses read-only tools (the "MCP"). It is not an agent (this is where things become dangerous). Spoofing? again, read-only.

[ndrean]

@nelsonic (Although this project does not use Reactor, thus wrong feed), an update of my natural language (ie AI-assisted) hexpm finder and github issue finder is more or less finished. I used the "tiny" ministral-smallmodel.

It boils down to:

• gh api search/issues -X GET -f q="org:dwyl oban
• curl -s "https://hex.pm/api/packages?search=icalendar

I built 3 (very small) MCP tools (using :ex_mcp) for the LLM to use it. Whenever you send a question (relevant to this app 😀), the app lets the LLM select the right tool and responds:

1. you can query info about hex packages,
2. you can search in public repos (eg dwyl) through the issues
3. you can save facts in memory (local SQLite with sqlite-vec for cosine)

✚ I added a RAG to enhance search with facts that you can save, for both packages and issues search. It will be injected into the prompt as a hint.

eg: "Bandit is the default Elixir HTTP server" to return Bandit rather than Cowlib

Even if I added a threshold (cosine < 0.7 and top 3 hints), there is a limitation with RAG explained below.

Firstly, one should preferably only save facts and not some preferences because injecting a preference can mislead the LLM if old preferences bleed into unrelated queries. But facts can also become outdated. For example, a default implementation can be changed which makes a statement like "the default package for na HTTP server is Bandit" become false. Another example: saving "I'm interested in LiveView issues in phoenixframework" would then surface on a query like "find issues about database performance in ecto" — and the LLM might still search phoenixframework instead of elixir-ecto.

Anyway, looks good. I will build this on my VPS instance and pass the URL, if you want to test. I can push the repo on Dwyl so you can check how it works if you are interested.

workflow

---
config:
  layout: elk
---
graph TD
    ChatLive["ChatLive<br/>(LiveView)"]
    WebhookController["WebhookController<br/>(Telegram)"]
    
    ChatLive --> Pipeline
    WebhookController --> Pipeline
    
    Pipeline["HexGh.Agent.Pipeline<br/><br/>Normalizes input:<br/>text → pass through<br/>audio → Transcriber → text"]
    
    Pipeline --> ProcessQuery["HexGh.Agent.process_query/2<br/><br/>1. Rate limit check<br/>&nbsp;&nbsp;&nbsp;Hammer: 20 req/min per user<br/>2. build_memory_context<br/>&nbsp;&nbsp;&nbsp;embed → sqlite-vec → XML<br/>3. Intent pass<br/>&nbsp;&nbsp;&nbsp;Mistral + tool schemas<br/>&nbsp;&nbsp;&nbsp;tool_choice: 'any'<br/>4. dispatch_tool → MCPServer.call_tool/2<br/>5. Synthesis pass<br/>&nbsp;&nbsp;&nbsp;Mistral with tool result"]
    
    ProcessQuery --> ToolsHex["Tools.Hex<br/>(Hex.pm API)"]
    ProcessQuery --> ToolsGitHub["Tools.GitHub<br/>(GitHub API)"]
    ProcessQuery --> ToolsSaveMemory["Tools.SaveMemory<br/>(embed + store)"]
    
    classDef entryPoint stroke:#818cf8,fill:#eef2ff
    classDef pipeline stroke:#2dd4bf,fill:#f0fdfa
    classDef process stroke:#a78bfa,fill:#f5f3ff
    classDef tool stroke:#fb923c,fill:#fff7ed
    
    class ChatLive,WebhookController entryPoint
    class Pipeline pipeline
    class ProcessQuery process
    class ToolsHex,ToolsGitHub,ToolsSaveMemory tool

Loading

Timing

To give an idea of how long to wrap these two miserable API calls with natural language input/output.

• research: how to hex.pm, github search repo issues): 2h
• plan architecture / process: which package to build MCP tools, add a RAG? why?yes/no/how?, DB choice SQLite, how to use sqlite-vec, which AI model when using MCP tools, compute embeddings...): 8h. I challenged gemini.
• scaffold minimal needed Phoenix, setup dependencies, check.
• Build a prompt to Claude code: 2h (gemini assistance for the write-up)
• Submit to Claude, discuss, plan, full action: from prompt to code. 2h discussion, then done in < 1h!
• Code review. Iterations...: 3-4h (?)
• Plan tests (per process, validate embeddings, RAG, per MCP tool, end-to-end) - all in text: 2h
• submit to Claude for action: 10min!
• check the test, debug, iterate changes....: 6h.
• setup container, run local validation: 30min
• quick AI assisted code review alkido 1min (zero finding)

=> Total: 2.5 days but AI has worked max 5-6h (?) probably, even if I used it all the time.

[ndrean]

Deployed.

1. webapp: https://hexgh.nlex.uk 🎉

2. Telegram: find user @HexGithub and just send messages. Nice rendering! ⭐️ It even accepts 🎤 messages (I added Mistral audio transcription voxtral-mini-latest). These AI services make apps so much more interactive.

[ndrean]

@nelsonic could you do me a favour?

I pushed a repo in Dwyl:: https://github.com/dwyl/local-hex-mcp. I am rather happy with my Elixir centric MCP, in particular a pretty neat Elixir Hexpm search engine. I believe it is really useful, for users, but also for Code assistants.

I would be glad it you can test it (one day..)

It is beta, some housekeeping is still needed, but the search is working pretty nicely

I pushed my latest version.

You will need to once (because it will be available locally on your machine):

• clone it,
• run MIX_ENV=prod mix setup,
• MIX_ENV=prod mix compile

Then in one of your Elixir repo of choice:

• grab a Mistral (free tier) API key,
• copy the AGENTS.md file from the fork into your repo,
• copy .mcp.json file from the fork into your repo
• start a Claude session and connect the MCP
• and ready to ask "search-docs package something".

Your db will be empty, so it will fetch it from hexpm and digest. I recommend to chose a "small but modern" library.
Modern means uses exdocs >0.30.

You will hopefully be surprised

[nelsonic]

@nelsonic been watching your work on the repo. 👌
Currently away from my desk so can't run anything on my iPhone / iPad ... 📱
But will try to run it on localhost when get back. 🤞