GSoC 2025: AI-Based API Response to Dynamic UI and Tool Generator

[animator]

Discussions on GSoC 2025 project
https://summerofcode.withgoogle.com/programs/2025/projects/hhUUM8wl

[synapsecode]

Meeting Notes (01.06.25)

Showed the Demo for AI Request Feature within API Dash

Pointers for me:
1.⁠ ⁠Submit the Draft PR
2.⁠ ⁠⁠Prompt TextFields must have labels to show what each one is
3.⁠ ⁠remove dividers in configs
4.⁠ ⁠⁠show RAW response also along with formatted output
5.⁠ ⁠⁠implement history
6.⁠ ⁠⁠show and edit endpoint in AI Request

[synapsecode]

02.06.2025

Implemented all the changes requested and raised PR (#850)

• Implemented Raw Response / Formatted Answer selector
• Implemented the full AI Request History Feature
• Implemented Editable URLs for AI Requests
• and other fixes mentioned in the previous call

This makes the entire AI Requests feature extremely robust. It also serves as the base for all future AI development on APIDash

[synapsecode]

05.06.2025

Gist of the Review done on AI Requests PR by Ankit

• Light Mode not considered
• No error handling when the user sends an empty AI request.
• Add Better null handling everywhere
• Enable Code Generation for AI Requests
• extraDetails is not the right approach, instead Create a new aiRequestModel which should switch
• No external hardcoded image URL is allowed.
• create a new package inside packages folder called genai where all LLM models, services and utilities must reside.
• Revisit Model Structure: Each model provider has their own api and params. And model is one of the parameters which is selected by the end user. (eg: OpenAI, Gemini, Ollama -> Model Providers; gpt-40, gemini-2.5-flash, llama3.1 -> Models)
• Available LLM providers should be in form of enum
• Review Safety of saving credentials in shared prefs inside settings_model
• Remove selectedAIRequestTypeProvider
• Remove file (ai_request_providers.dart)
• ai_req_configs: Simplify the code by breaking into modular parts
• api_type_dropdown: .update(url: defaultModel.specifics.endpoint) does not conform to clean code
• remove (APIType.ai => FlutterLogo()) in request_body.dart
• DropdownButtonAIMethod is not in the correct location
• remove (stac) from current PR
• revert flex_color_scheme to ^8.2.0
• response_body_success.dart: adding ansewer tab needs a better approach
• pick a good color instead of APIType.ai => kColorSchemeSeed

need to make these changes to make the AI Requests production ready.

the core point is to remove extraDetails completely and replace it with a completely separate model. Will need a bit of extra thinking or might need to discuss approaches with Ankit.
will be a major code change i feel

[synapsecode]

06.06.2025

Whole day was spent re-working the genai foundations
A new package was created called apidash_genai whcih handles all the generative AI needs of the client. It is a dart friendly package that means it can be used by native dart also

Sample Code Examples:

Directly Using a Model (eg: Gemini)

final LLMModel model = GeminiModel.gemini_20_flash;
final ModelController controller = getLLMModelControllerByProvider(model.provider);
final payload = controller.inputPayload;
payload.systemPrompt = 'Say YES or NO';
payload.userPrompt = 'The sun sets in the west';
payload.credential = 'AIza....';
final genAIRequest = controller.createRequest(model, payload);
final answer = await GenerativeAI.executeGenAIRequest(model, genAIRequest);
print(answer)

Calling a GenAI Model using the provided helper

final geminiModel = GeminiModel.gemini_15_flash_8b;
GenerativeAI.callGenerativeModel(
    geminiModel,
    onAnswer: (x) {
        stdout.write(x);
    },
    systemPrompt: 'Give a 100 word summary of the provided word. Only give the answer',
    userPrompt: 'Pizza',
    credential: 'AIza.....',
    stream: true
);

Additionally, More Providers such as:

• Gemini
• Ollama
• OpenAI
• AzureOpenAI
• Anthropic

Were added to the providers folder along with all of their models as an enum type
This set the foundation for genai within apidash

The old PR branch (#850) is now not considered anymore because major chunks had to be reworked, it was better to rewrite it from the ground up

[synapsecode]

07.06.2025

Whole day was spent in integrating this apidash_genai package into the apidash client (a fresh start)

the first thing that was done was the creation of the LLMSelectorWidget and its subsequent integration into apidash's settings page & settings model

Next,
A major change was done. to get rid of the old extraDetails implementation and have a separate Model for AI, the RequestModel gets rid of 2 attributes: httpRequestModel and httpResponseModel in favour of genericRequestModel and genericResponseModel

@freezed
class GenericRequestModel with _$GenericRequestModel {
  const GenericRequestModel._();

  @JsonSerializable(
    explicitToJson: true,
    anyMap: true,
  )
  const factory GenericRequestModel({
    required AIRequestModel? aiRequestModel,
    required HttpRequestModel? httpRequestModel,
  }) = _GenericRequestModel;

  factory GenericRequestModel.fromJson(Map<String, dynamic> json) =>
      _$GenericRequestModelFromJson(json);
}

This is done to make the whole system modular and enable future extension.
The subsequent changes were made on a platform wide level, (MAJOR CHANGE)

The remainder of the day was just involved in Adding the Prompt, Config and Authorization tabs to the AI Requests and polishing it

By 8th Jun 2025, I will be ready with the AI Requests Feature (BEFORE ANY IMPROVEMENT SUGGESTIONS ARE GIVEN)

[synapsecode]

Quick Huddle with Ankit at 8th June

Points raised after seeing the progress so far:

• prevent usage of functions and instead find a way to incorporate them into the enums itself
• remove the local provider and remote provider stuff, unnecesary
• fix the LLMSelector UI/UX remove the edit icon and instead make the model name itself clickable (tonality, hover etc)
• rename apidash_genai to genai
• use the apidash_core http request interfaces instead of redefining stuff using http package
• stop using enums for model names as new ones keep coming, instead look into a JSON approach where the json map is stored on our repo for example and we can fetch it from there and lcoally cache it or something
• Move the ai_request and ai_response models to genai folder instead of apidash_core
• move the generic_request and generic_reponse into apidash lib instead of apidash_core

[synapsecode]

Progress on 08.06.2025

• all external enum specific methods such as llmProviderFromJSON have been moved inside the enums itself
• renamed apidash_genai to genai
• added streamHttpRequest to apidash_core and started using apidash_core in genai instead of http
• AI Request Configuration Widgets (sliders for temperature etc) logic was refactored as suggested by Ankit
• collection_providers::sendRequest: updated to fully handle AI Requests via GenericRequestModel, which means that requests can now be made and responses can be seen
• AI Request History & Duplication Feature implemented: Full AIRequest Compatable history and history duplication implemented

[synapsecode]

Progress on 09.06.2025

• Added LLMProvider to AIResponseModel so that we can use its output formatter to get AI answers from the returned Map
• implemented the Answer Tab along with Raw Requests, this uses the model output formatter to give a clean response
  
• AI Requests: Fixed a Null Check error on Request Duplication and also fixed a LLMInputPayload Shallow Copy / Reference bug via cloning

[synapsecode]

10.06.2025

Almost all tasks related to AI Requests are complete except (including those from previous PR):

• using remote json instead of enums for models
• enabling AI Code Generation
• Reviewing Safety of storing LLM Credentials in SettingsModel SharedPrefs

these can wait until the whole feature is deemed good by Ankit. After that I will implement this.

[synapsecode]

AIREQVID.mp4

[synapsecode]

11.06.2025

• Draft PR Created: AI Requests Feature (LEGACY) #856

[synapsecode]

Pointers after Meeting on 14.06.2025

• Generic Request & Response models need to be scrapped and instead must come inside RequestModel itself
• properly export all contents in genai and import only genai/genai.dart inside codebase
• remove LLMSelector and other UI from genai package and add it into apidash codebase
• GenerativeAI class should be out of genai/genai.dart as genai.dart should be an exporter only
• revisit streamHttpResponse in terms of request cancellation
• Re-Architect the whole LLM model architecture away from enums and onto a remote json derivative. Also allow manual additions and allow for update
• add an example folder to the genai package showing exact usage and prepare for public release
• all of the networking logic inside apidash_core should be moved into a new public package better_networking
• try to implement initializeAIRequest as Model Defaults

Basically, the plan for now is to
create better_networking as a separate PR and get it merged
Next, use that inside genai package to get it reviwed & merged (with the enum swap)

Lastly, Merge this updated code with the current ai_requests_feature

[synapsecode]

15.06.2025

• Successfully reverted from GenericRequestModel and GenericRequestModel to using AI Req/Res models directly inside RequestModel
• Fixed GenAI import & export to simplify imports everywhere
• LLMModel enum architecture removed and replaced by a Remote LLM Fetching implementation using github repo hosted models.json file, Includes Manual Model additions all saved in shared prefs with fetch ability, Includes Ollama model fetching

[synapsecode]

16.06.2025

apidash_core all networking components moved into better_networking package
better_networking: greatly improved the streaming & cancellation ability

[synapsecode]

17.06.2025 & 18.06.2025

• Created the Standalone PR for better_networking package (better_networking Package Creation #857)

[animator]

better_networking TODO:

• Add tests (full code coverage)
• Improve README

[synapsecode]

Meeting on 29.06.2025

• better_networking package was merged to main branch and ankit mentioned how I must add tests and improve readme
• also discussed the future development approach for the product

the progress so far is:

• better_networking
• enable sse & streaming (in-progress: SSE & Streaming Support for BetterNetworking #861)
• genai foundational package creation (in-progress)
• AI Requests feature within APIDash (in-progress)
• AI UI Designer (poc-complete)
• AI Tool Creator (poc-complete)

Documentation for Testing: https://github.com/foss42/apidash/blob/main/doc/dev_guide/testing.md

[synapsecode]

ToDos after meeting on 02.07.2025

SSE PR: (#861)

• use convertStreamResponse utility instead of manually creating a HttpResponse from SR
• improve UI and add finishing touches (Eg: card colour etc)
• reverse the order to have latest values on top in SSE
• figure out all the possible streaming resp-types and add it to a common place in better_networking instead of conditional in code
• isTextStream should be made nullable and null at first instead of complicated reset logic, also the block should execute only once instead of each time
• move SSEDisplay widget into another place on the UI Layer
• stop assuming response is in utf8 by default (solved by using convertStreamResponse)
• Add Tests for SSE in better_networking
• Add Tests for the sendRequest and other collection provider stuff after SSE change
• What about GraphQL requests? is it compatible with streamHttpRequest as it is being used everywhere now

[synapsecode]

UPDATE: convertStreamResponse cannot be used as in our case, we are converting each chunk of the streamed data into a response.
convertStreamResponse waits for the whole stream to conclude before giving output. This behaviour is blocking and doesnt meet the realtime requirements of SSE

[animator]

Because for some reason you are using streamTextResponse to convert the bytes in stream into text and then reconverting the text into bytes for HttpResponse.bytes()