What is a Component in Iguana?
When people start working in Iguana, one idea shapes how they build interfaces: Components. They are the basic units that let Iguana stay modular, organized, and easy to manage over time. Before looking at how Components work under the hood, it helps to understand what they are meant to solve.
Why Iguana Uses Components
Healthcare integrations involve many moving parts. An interface often needs to:
- Receive or poll data
- Transform or clean messages
- Map fields
- Make routing decisions
- Communicate with outside systems
- Handle retries and errors
- Store configuration or state
Without structure, all of this ends up blended together in a single pile of logic. It becomes hard to manage, hard to update, and hard to reuse across projects.
Components break this pattern. Instead of one large script doing everything, Iguana organizes work into small focused units. Each one has a clear purpose and clear boundaries. When you connect several Components together, you get a complete interface.
What a Component Is
A Component is a self-contained building block. It includes:
- A frontend card in the UI where users enter configuration and settings
- A backend Translator project where all the scripting code and logic lives
You can think of a Component as a small service that lives inside Iguana. It has a defined job, its own settings, and its own source code.
Why This Model Works Well
Components make interfaces easier to understand
When each part of the system has one job, the whole interface is easier to follow. You can look at a list of Components and know what each one does without digging through a giant script.
Teams can collaborate cleanly
The visual card holds the settings. The Translator holds the logic. This lets developers focus on code and lets administrators adjust configuration without touching it.
Everything is tracked
All Component code is stored in Git, which means changes are captured, reviewed, and versioned. This is important for reliability and testing.
Reuse becomes natural
If you build a good listener, mapper, or sender, you can reuse it everywhere. You only change the settings on the configuration card, not the source code.
Components scale with your needs
If you need more throughput, you can run multiple copies of a Component. If you need more steps in a workflow, you add more Components. The structure grows with the project.
Systems become more self explanatory
A well named Component with clear settings often tells a new team member everything they need to know. Less time is spent tracing scattered logic.
How to Think About Components
A good way to picture Components is as building blocks in a pipeline. One block receives data. Another filters or translates it. Another posts it to an API. Another handles logging or queues it for later. Each block is simple by itself, but together they form a complete and reliable flow.
This modular style helps interfaces stay clean and flexible. It also makes them easier to maintain when requirements change, which is common in real healthcare environments.
