How do their APIs compare?

API Comparison: conductor-oss/conductor vs graphql-java/graphql-java

These two projects have fundamentally different API shapes because they solve different problems — one is a durable workflow orchestration engine, the other is a query-execution library for the GraphQL spec.

conductor-oss/conductor: task/tool-oriented, config-driven API

Conductor's surface area (at least in the retrieved code) is centered on system tasks and tool configuration objects, not a single unified execution entrypoint:

• Tool compilation is declarative and map-based. ToolCompiler maps SDK-level tool type strings (worker, http, mcp, agent_tool, generate_image, rag_index, etc.) onto Conductor task types (SIMPLE, HTTP, CALL_MCP_TOOL, SUB_WORKFLOW, LLM_INDEX_TEXT, ...) via a static TYPE_MAP [agentspan/.../compiler/ToolCompiler.java:L138-L152]. The public API here is "compile a list of ToolConfig into tool spec maps" [agentspan/.../compiler/ToolCompiler.java:L155-L162].
• Tasks are self-describing via input/output data contracts, documented in prose rather than strict typed interfaces — e.g. LLM_SEARCH_INDEX takes vectorDB, namespace, index, query, and returns results [ai/README.md:L275-L292], and ListApiToolsTask documents its specUrl/headers input and its tools/baseUrl/format output as a JSON-shaped contract in Javadoc [agentspan/.../ListApiToolsTask.java:L33-L52].
• Extension points are class-based (abstract classes to subclass), e.g. adding a new vector DB means extending VectorDB and implementing updateEmbeddings(...) and search(...) [ai/CONTRIBUTING.md:L295-L321].
• Normalization/adaptation layers translate external formats (e.g., OpenAI tool definitions) into Conductor's internal ToolConfig via switch-based type dispatch — WebSearchTool, FileSearchTool, FunctionTool, AgentTool, etc. [agentspan/.../OpenAINormalizer.java:L159-L193].
• Runtime introspection is done by inspecting TaskModel/WorkflowModel fields (e.g. resolveToolName reads inputData.method or output data depending on how the workflow was compiled) [agentspan/.../AgentEventListener.java:L429-L444], rather than through a stable typed API — this is inherently more brittle/coupled to internal conventions.

Overall, Conductor's API here is loosely-typed, map/JSON-centric, and configuration-driven — appropriate for a workflow engine that needs to interoperate with many external tool/agent SDK formats.

graphql-java/graphql-java: strongly-typed, builder-based execution API

GraphQL-java exposes a much more classical typed, fluent Java API centered on one entrypoint class, GraphQL:

• Single execution entrypoint with multiple overloads: execute(String query) [src/main/java/graphql/GraphQL.java:L384-L389], execute(ExecutionInput.Builder) [L399-L402], and a lambda-friendly builder-function variant, all funneling to a core execute(ExecutionInput).
• Async-first design: executeAsync(...) mirrors the sync overloads but returns CompletableFuture<ExecutionResult> [src/main/java/graphql/GraphQL.java:L451-L490], and internally wires in an EngineRunningState/Profiler for execution tracking [L487-L490].
• Strongly-typed result contract: ExecutionResult is an interface with typed methods — getErrors() returning List<GraphQLError>, generic <T> T getData(), isDataPresent(), getExtensions() — directly modeling the GraphQL spec's rules about when data should/shouldn't be present [src/main/java/graphql/ExecutionResult.java:L18-L57].
• Validation/parsing as separate, explicit steps: `