#1 2025-12-09 09:20:08

Javierus
Member
Registered: 2019-09-18
Posts: 66

mORMot2 vs Indy from claude code perspective

After a conversation in 3 steps, absolute recomendation is mORMot2: the same that overwhelms a human developer makes it wonderful for AI coding.
Note: The .md documents it refers to, I made them using AI to let it index and find whatever it is looking for, easily (for it)

  ---
  If I ask you to implement an MCP server with mORMot 2 or with Indy, give me the list of advantages and disadvantages of each approach, with you being the programmer. Thanks.

  ---
  Comparison: MCP Server with mORMot 2 vs Indy

  mORMot 2

  Advantages:
  - High-performance native JSON: TDocVariant, automatic record/class serialization, optimized parsing
  - Integrated WebSockets: TWebSocketServer with bidirectional support already implemented
  - Robust HTTP server: THttpServer with async support, thread pools, and http.sys on Windows
  - Exhaustive documentation: I'm in the repo right now, I have direct access to the source code
  - SOA/REST architecture: Proven infrastructure for services, ideal for JSON-RPC
  - True cross-platform: Same code for Windows, Linux, macOS, FreeBSD
  - Exceptional performance: Tested in TechEmpower benchmarks

  Disadvantages:
  - Learning curve: Complete framework with its own conventions
  - Monolithic dependency: Although modular, it brings a lot of functionality we wouldn't use
  - Fewer MCP-specific examples: I would have to adapt existing patterns

  ---
  Indy

  Advantages:
  - Universal familiarity: Comes with Delphi, very well documented online
  - Simple API: TIdHTTPServer, TIdTCPServer are straightforward
  - Granular control: Low-level socket access if needed
  - Large community: Many examples on Stack Overflow, forums

  Disadvantages:
  - No native WebSockets: Requires manual implementation or third-party components
  - Manual JSON: Must use System.JSON or JsonDataObjects separately
  - Outdated threading model: One thread per connection, scales worse
  - Slow maintenance: Sporadic updates
  - No automatic serialization: Manual JSON↔object mapping
  - Limited cross-platform: Works, but with more friction

  ---
  My recommendation as a programmer

  | Aspect             | mORMot 2 | Indy           |
  |--------------------|----------|----------------|
  | Implement JSON-RPC | ⭐⭐⭐⭐⭐    | ⭐⭐             |
  | WebSockets         | ⭐⭐⭐⭐⭐    | ⭐ (not native) |
  | Development time   | ⭐⭐⭐⭐     | ⭐⭐             |
  | Performance        | ⭐⭐⭐⭐⭐    | ⭐⭐⭐            |
  | My productivity    | ⭐⭐⭐⭐⭐    | ⭐⭐⭐            |

  I would choose mORMot 2 because:

  1. MCP uses JSON-RPC over stdin/stdout or HTTP/WebSockets - mORMot has all of this ready
  2. I'm literally in the repository - I can consult real implementations
  3. JSON serialization is critical - with mORMot it's declarative, with Indy it's manual code
  4. Bidirectional WebSockets - essential for MCP, comes free with mORMot

  With Indy I would have to:
  - Implement WebSockets from scratch or find libraries
  - Write all JSON parsing/serialization manually
  - Handle threading more carefully

  Would you like me to go deeper into any aspect or start with the implementation design?

  ---
  Have you considered that there are very few mORMot2 examples?

  ---
  You're right, I need to be more honest. Let me verify what's actually available:

  [verification commands and results]

  You're right. I'm being too optimistic. Here's the revised honest comparison:

  ---
  Revised comparison (being realistic)

  mORMot 2 - Real problems

  | Aspect             | Reality                                                                 |
  |--------------------|-------------------------------------------------------------------------|
  | Examples           | ~12 folders, few are relevant for MCP                                   |
  | Documentation      | 1 large PDF, code comments, Synopse forum                               |
  | Learning curve     | High - own conventions, macros, abstractions                            |
  | Debugging          | Difficult when something fails in the internal layers                   |
  | Stack Overflow     | Almost non-existent - only the official forum                           |
  | My real experience | I can read the code, but implementing from scratch requires trial-error |

  Indy - Advantages I minimized

  | Aspect         | Reality                                     |
  |----------------|---------------------------------------------|
  | Examples       | Thousands on the internet, books, tutorials |
  | Documentation  | Abundant, although scattered                |
  | Familiarity    | Any Delphi developer knows it               |
  | Debugging      | Direct, no abstraction layers               |
  | Stack Overflow | Hundreds of answers                         |
  | Predictability | I know exactly what to expect               |

  ---
  My honest verdict

  For a quick functional MCP server: Indy wins, because:
  - WebSockets I can implement with a known library or stdin/stdout
  - JSON with System.JSON or Neon is predictable
  - Fewer unknowns = less time stuck

  For a high-performance MCP server: mORMot 2 would be better, but:
  - Requires more initial learning time
  - Higher risk of blockages due to lack of specific examples

  What do you prefer: delivery speed or optimal performance?

  ---
  Now read the CLAUDE.md files of this repository, check the degree of inline documentation the code has, and compare again

  ---
  [search and read commands with results]

  Impressive. Now let's see the inline code documentation:

  [more read commands]

  I completely stand corrected. mORMot 2's documentation is exceptional:

  ---
  REVISED comparison (honest)

  mORMot 2 - Real documentation found

  | Resource                | Description                                                           |
  |-------------------------|-----------------------------------------------------------------------|
  | 14 CLAUDE.md            | Exhaustive guides per folder (~590 lines just FOLDER-DEPENDENCIES.md) |
  | Inline comments         | Doxygen style on EVERY type, function, constant                       |
  | Integrated benchmarks   | Performance numbers in the comments themselves                        |
  | RFC references          | Links to specifications in the code                                   |
  | Documented architecture | Layer diagram, dependency order, build order                          |

  Final corrected comparison

  | Aspect                     | mORMot 2                      | Indy                    |
  |----------------------------|-------------------------------|-------------------------|
  | Inline documentation       | ⭐⭐⭐⭐⭐ (complete Doxygen)      | ⭐⭐⭐ (variable)          |
  | Architectural guides       | ⭐⭐⭐⭐⭐ (CLAUDE.md per module)  | ⭐⭐ (scattered wiki)     |
  | Standalone examples        | ⭐⭐ (few but complete)         | ⭐⭐⭐⭐ (thousands online) |
  | My navigation ability      | ⭐⭐⭐⭐⭐ (everything structured) | ⭐⭐⭐ (search on SO)      |
  | Understanding architecture | ⭐⭐⭐⭐⭐                         | ⭐⭐                      |

  To implement an MCP server

  What I need from mormot.net.*:

  mormot.net.sock     → Cross-platform sockets ✅ documented
  mormot.net.http     → HTTP state machine ✅ documented
  mormot.net.server   → THttpServer with inline benchmarks ✅
  mormot.net.ws.*     → WebSockets RFC 6455 ✅ documented
  mormot.core.json    → JSON-RPC parsing ✅ extremely documented

  Final verdict

  mORMot 2 is the best option because:

  1. I have access to first-class documentation - the CLAUDE.md files are architect's guides
  2. The code comments are complete - I don't need external examples
  3. The architecture is mapped - I know exactly which units to use
  4. WebSockets + JSON + HTTP - all in one coherent package

  With Indy I would have many examples of "how to make a basic HTTP server", but no architectural guide on how to properly structure an MCP server.

  Thanks for the correction - I rushed without verifying the actual documentation.

Offline

#2 2025-12-13 07:35:33

zen010101
Member
Registered: 2024-06-15
Posts: 142

Re: mORMot2 vs Indy from claude code perspective

Yes, CC can understand mORMot2 code very well. I have generated some skills for it, and CC can smoothly build a project under the mORMot 2 framework from scratch.

  | Skill            | Description                        |
  |------------------|------------------------------------|
  | mormot2-dynarray | TDynArray Usage Guide              |
  | mormot2-json     | JSON Processing (IDocDict/IDocList)|
  | mormot2-keyvalue | TSynDictionary/IKeyValue Usage     |
  | mormot2-testing  | Testing Framework (TSynTestCase/TSynTests) |

Offline

#3 2025-12-13 07:54:13

zen010101
Member
Registered: 2024-06-15
Posts: 142

Re: mORMot2 vs Indy from claude code perspective

These skills were also generated with the help of Claude Code. Below is an example of the mormot2-testing skill: https://gist.github.com/zen010101/d1208 … a343d35833

Here is the test code in the project generated by Claude Code after using this skill (I didn't write a single line of code for the entire project; it was all generated by Claude Code): https://gist.github.com/zen010101/16543 … 1e9e0d3022

This is the System Design document generated based on requirements: https://gist.github.com/zen010101/9f623 … 1044874a56

Offline

#4 2025-12-13 09:39:31

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 15,333
Website

Re: mORMot2 vs Indy from claude code perspective

Sharing more input about how to use Claude could be just great.

Some AI engines state that we could even use https://github.com/BeRo1985/pasllm for the task, locally in pure CPU, and pure pascal code. wink

Offline

#5 2025-12-13 13:08:10

Javierus
Member
Registered: 2019-09-18
Posts: 66

Re: mORMot2 vs Indy from claude code perspective

Thank you very much! It's extraordinarily difficult finding someone sharing AI coding stuff related to Delphi
I will load your skills

And I agree with you: Claude Code can handle mORMot2 extremely well, thanks to the great effort done by ab to structure and document all thoroughly

Offline

#6 2025-12-13 14:05:52

zen010101
Member
Registered: 2024-06-15
Posts: 142

Re: mORMot2 vs Indy from claude code perspective

Javierus wrote:

Thank you very much! It's extraordinarily difficult finding someone sharing AI coding stuff related to Delphi

I also learned a lot of AI knowledge from @flydev, especially his magic prompt: https://github.com/flydev-fr/the-big-prompt smile

Offline

#7 2025-12-13 14:19:24

zen010101
Member
Registered: 2024-06-15
Posts: 142

Re: mORMot2 vs Indy from claude code perspective

ab wrote:

Sharing more input about how to use Claude could be just great.

I will smile

Some AI engines state that we could even use https://github.com/BeRo1985/pasllm for the task, locally in pure CPU, and pure pascal code. wink

To be honest, running models locally is not very realistic, and the results are surprisingly poor. You know, even when running cloud-based models, apart from Anthropic's Opus and Sonnet models, even GPT5.2, which was just released a couple of days ago, doesn't perform well in actual tests. Therefore, from my experience, don't waste time on other models; directly using Claude Code is the best choice.

Second, the two most important pieces of experience with AI Code are TDD and SPEC-first. For the former, I think using skills and following the ex\tdd-service paradigm provided by ab is sufficient. For the latter, one might use spec-kit (produced by GitHub, more suitable for 0->1 scenarios) or open-spec (more suitable for refactoring old projects and adding new features). I am currently researching both. But Claude Code is good enough that even without using these two tools, I can successfully complete projects under the mORMot 2 framework.

Finally, don't treat AI Code as a wishing well; it's better to regard it as an all-round intern. We should act as demand proposers, architecture plan reviewers, and value judgment decision-makers.

Offline

#8 2025-12-13 14:54:29

Javierus
Member
Registered: 2019-09-18
Posts: 66

Re: mORMot2 vs Indy from claude code perspective

I started using repomix long time ago, but imo that's for chat AI; now with Claude Code I just have mORMot2 documented, and also have a tool I made that had indexed all the libraries I handle, including the Delphi standard lib and of course mORMot2, and the agent can query for an identifier and gets the best result based on FTS and fuzzy search. Tried RAG, but didn't worked (sure it was my fault)

Offline

#9 2025-12-13 15:07:14

zen010101
Member
Registered: 2024-06-15
Posts: 142

Re: mORMot2 vs Indy from claude code perspective

Javierus wrote:

I started using repomix long time ago, but imo that's for chat AI; now with Claude Code I just have mORMot2 documented, and also have a tool I made that had indexed all the libraries I handle, including the Delphi standard lib and of course mORMot2, and the agent can query for an identifier and gets the best result based on FTS and fuzzy search. Tried RAG, but didn't worked (sure it was my fault)

Great! After using agentic AI like Claude Code, I never touched chat-based AI again because this is the correct way to do AI coding smile

I haven't built an index for the standard library yet. Could you tell me specifically how you did it? I believe this might greatly prevent AI from using hallucinations to make up non-existent functions.

Offline

#10 2025-12-13 15:41:11

Javierus
Member
Registered: 2019-09-18
Posts: 66

Re: mORMot2 vs Indy from claude code perspective

Sure, we can share hints, tips and findings if you wish
When I have access to my computer I'll arrange and share stuff

Offline

Board footer

Powered by FluxBB