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]

both of these tasks are now complete!

[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 new decodeBytes utility in http_response_utils)
• 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()

[synapsecode]

that was a leftover artefact form the prototype genai streaming implementation. have removed it.
however i still cannot use convertStreamingResponse as this expects the stream to be finite

Future<http.Response> convertStreamedResponse(
  http.StreamedResponse streamedResponse,
) async {
  Uint8List bodyBytes = await streamedResponse.stream.toBytes();

  http.Response response = http.Response.bytes(
    bodyBytes,
    streamedResponse.statusCode,
    headers: streamedResponse.headers,
    persistentConnection: streamedResponse.persistentConnection,
    reasonPhrase: streamedResponse.reasonPhrase,
    request: streamedResponse.request,
  );

  return response;
}

note the await usage,
however for most SSE implementations, it doesnt really end on its own so this will await forever which is not the behaviour we want.
i have addressed this and will show it to you in the next meeting

[synapsecode]

UPDATE: GraphQL support has been added to streamHttpRequest & TCP limit clipping issue also fixed

[synapsecode]

UPDATES:

http_service.dart: the original sendHttpRequest function contents were completely replaced by streamHttpRequest. All the prior testcases for sendHttpRequest have passed which mean it was a successful transfer. This reduces code duplication and maintainence needs

Future<(HttpResponse?, Duration?, String?)> sendHttpRequest(
  String requestId,
  APIType apiType,
  HttpRequestModel requestModel, {
  SupportedUriSchemes defaultUriScheme = kDefaultUriScheme,
  bool noSSL = false,
}) async {
  final stream = await streamHttpRequest(
    requestId,
    apiType,
    requestModel,
    defaultUriScheme: defaultUriScheme,
    noSSL: noSSL,
  );
  final output = await stream.first;
  return (output?.$2, output?.$3, output?.$4);
}

makeStreamedRequest was implemented and refactored out of streamHttpRequest for maintainability and separation of concerns reasons

streamHttpRequest: implementation was refactored & modified to support chunking and expansion. This prevents gzip errors, TCP packet cutoffs, encoding issues and a lot more. It also makes the code more robust in terms of cancellation (for streaming requests)

stream_request_test.dart: contains the latest tests targetted at streamHttpRequest functionality. As of now covered actions are: (REST, GQL, SSE, SSE Cancellation). More to be added in the coming days.
will also need to set up a meeting with ragul to check coverage and discuss detailed testing approach for better_networking

[synapsecode]

meeting notes with Ragul; 06.07.2025

pointers:

1. run the coverage metric on better_networking specifically to see all the gaps in testing
2. testing folder structure should mimic the code's actual folder structure
3. look into the spot package for widget-level testing if needed
4. Ragul was happy with the sse implementation

overall the agenda now is to get testing coverage up from ~38% to a higher number. closer to 70-80% or more. That would be a good end to the better_networking PR

after that i can proceed to work on genai

[synapsecode]

Original Coverage:

[synapsecode]

Latest Coverage:

I have achieved the desired coverage.
some tests were manually written but a majority of them were generated via chatgpt. once generated, I go through the test and make the needed modifications to check if it works in the way i want.

[synapsecode]

UPDATE: As ankit had requested, I have written a test for collection_provider modifications & the new SSEDisplay output too. Basically, we are checking if the SSE output comes on the screen or not

Now the only thing pending is:

• updated README
• Improving & Finalizing the UI (adapt for dark mode etc)

[synapsecode]

UPDATE: README updated for better_networking and dark mode support added to SSE Display

The SSE PR is ready to be reviewed merged: #861

[synapsecode]

UPDATE: 16 Jul

• RAW Response Support added to SSE
• SSEDisplay: kCodeStyle used instead of monospace on Ankit's suggestion as it is a battle-tested style
• genai package and AIRequests Feature have been built on top of current SSE branch, once merged to main I will be doing a rebase and within a few days both those features should be ready

[synapsecode]

Meeting notes @ 18 July

• SSE PR will be merged and pushed to main by weekend
• finish up genai package (rebased)
• finish up AIRequests feature fully & add Streaming output support enabled by SSE
• Start focusing on the Core GSoC project now (AI UI Designer)
• Start finalizing your prompt and agent designs
• Look at smallagents python library to get inspiration for your own agentic framework (eg: plan, apply and verify loop)

[synapsecode]

Meeting Notes @ 15 Aug

• GenAI & AIRequests PR is actively being refactored and reviewed
• add an AI Model Selector inside tool generator UI so that the user can select (same widget as settings)
• fork Stac and make any necessary changes (onError callback, etc)
• python syntax highlighting not working, use exact same highlighter used in codegeneration UI
• selected model is not available in history page
• FIX ISSUE: out of bounds highlight when model in selector is partially scrolled
• FUTURE FEATURE: Remove Delete button next to model and replace it with Heart to "Add to Favourites"

[synapsecode]

TOOL GENERATION RESEARCH DOCUMENT LINK: https://docs.google.com/document/d/17wjzrJcE-HlSy3i3UdgQUEneCXXEKb-XNNiHSp-ECVg/edit?tab=t.0

[synapsecode]

Draft PR for AI UI Designer and ToolGeneration (intended for maintainers to review progress)

Link to PR: #874

[synapsecode]

Upcoming Tasks

• narrowing down to a limited list of supported widgets for better accuracy
• SDUI Error Handling and fallback (need to manually modify Stac package by forking)
• improving the system prompt to generate a better UI on the first try by trying to extract optimal layout information
• handling cases where SDUI output is too big and model output is getting clipped

[synapsecode]

TODO after meeting on 29 Aug

• Add as many examples for AI UI Designer into final report as possible (1/4 done)
• Add a Video Demonstration of the UI Designer in action along with modification
• fix responsiveness in widgets for aiuigen and toolgen