#Redundancy and Choice for External Dependencies

1 messages · Page 1 of 1 (latest)

severe vessel
fathom swallow
#

@severe vessel @dapper warren Sir, I understand the task and believe I can contribute effectively to the relevant projects where this can be implemented.

I am a second-year B.Tech student at the Indian Institute of Information Technology (IIIT), Sonepat, and I have good working knowledge of Next.js and TypeScript.

One possible approach could be to add a button that opens a dialog-style interface, where we list all the required external APIs along with clear instructions on how users can obtain and configure them.

I would appreciate your feedback on this approach and would be happy to refine it further based on your suggestions.

dapper warren
fathom swallow
#

Okay then I can work upon those with next js or mern as tech stack

dapper warren
#

Not necessarily, all our projects have different tech stacks

fierce dragon
#

Multi-LLM provider support is necessary.
We should have options of providers like Anthropic and Openai along with the free tier APIs like gemini, openrouter and groq and more.

#

We can also have the option for local LLM support, like ollama and LMStudio.
Some people do have powerful GPUs and can use local LLMs on their systems

#

We can use tools like Litellm or Vercel AI SDK for this or build it by ourselves depending on the project.

finite sky
#

@dapper warren hey , i want to clarify something , will the user set this api or the llm key in the env or in the frontend , ie before running or after running the project , can you please tell me about this i am little confused
Thanks!

dapper warren
noble sinew
#

@dapper warren I’m Sagar, a CS student from India preparing for GSoC 2026. I have experience with Python, ML projects, and some open-source contributions (including scikit-learn).

I’ve been going through the discussion on the CHOICE idea. From my understanding, the core tasks involve:

  1. Bring Your Own API Key via frontend settings
  2. Supporting multiple providers (OpenAI, Gemini, Groq, local models like Ollama, etc.)

Would it be a good approach to design a common provider abstraction layer (e.g., an LLMProvider interface) so switching APIs does not affect core logic?

Also, which AOSSIE project would be the best starting point to implement BYOK + multi-provider support?

severe vessel
#

Would it be a good approach to design a common provider abstraction layer (e.g., an LLMProvider interface) so switching APIs does not affect core logic?

Yes.

Also, which AOSSIE project would be the best starting point to implement BYOK + multi-provider support?

Finding the projects that are in most need of this is part of the challenge.

noble sinew
#

okay @severe vessel , I’ll review the existing projects to better understand where such an abstraction would have the most impact. Thanks for the clarification.

finite sky
#

hi @severe vessel @kind moon
I’ve implemented a v1 of a library that addresses the “Redundancy and Choice for External Dependencies” requirement.

This version supports:

✅ Bring Your Own Key (BYOK) — users can configure and store their own API keys in local storage.

✅ Provider selection — users can choose between multiple API providers (e.g., different LLMs) from project settings.

✅ First-time configuration flow — users are guided to set up their API key when they use the project for the first time.

But the main issue is adaptability all the ai related projects have different architecture we need to change something in the projects codebase to use this feature , but the upcoming projects can add this , so for the already implemented codebases i really want your mentorship and guidance

Also the backend that is written in node and python is my primary vision coz maximum are written in these two but what about code written in go or c++ , or should i focus on node and python only for now

looking forward for you response
Thank you

severe vessel
finite sky
#

Hi @severe vessel , great point — and you're right for the majority of cases.

For new projects or projects where the AI call is made directly from the browser (like a simple chat UI), a pure frontend component is absolutely sufficient. The user's key lives in localStorage, and the fetch goes directly to Groq or Gemini — no backend needed at all. That's the primary vision going forward.

The backend middleware exists specifically for existing AOSSIE projects that already have server-side agent logic — LangGraph graphs, multi-agent pipelines, tool calls, server-side memory — where the LLM is initialized in Python or Node, not in the browser. In those cases the key has to travel from localStorage → HTTP header → backend, because there's no way for a browser fetch to inject a key into a Python process directly.

So to clarify the two cases:

New or frontend-only projects → pure frontend component, zero backend change needed
Existing projects with server-side agents → frontend stores the key, sends it as a header, backend reads it and passes it to the LLM constructor — all other agent logic (graphs, prompts, tools) stays untouched
Going forward, should I prioritize the pure frontend path and treat the backend middleware as a secondary integration guide for existing projects? Also, for existing codebases — would you prefer I pick 1-2 specific AOSSIE projects and demonstrate the full integration end to end, rather than keeping it generic?

Tell me if i did not get anything or am i missing something here
Thanks

finite sky
#

@severe vessel @dapper warren hi ! , so we actually used the library in a working project , and just wanted to know your view on this
Also if all things are ok , i was thinking to open a pr for this which will change some architecture decisions of the project so please give me guidance on this
Thank you

finite sky
#

i have added above in the perspective channel , but since it uses the choice feature so i thought to post it here also
Thanks

dapper warren
finite sky
orchid shadowBOT
#

@finite sky You are now level 5! :confetti_ball:

severe vessel
#

Couldn't the BYOK frontend component have some sort of callback configuration that allows an existing project to configure the component in such a way that, when a key is inserted, the project's own backend is called via the callback?

finite sky
#

@severe vessel
Mental Model :

User types their Groq key into your app
↓
Library saves it in THEIR browser (localStorage) — never your server
↓
Every request from your frontend automatically carries the key as 3 headers
↓
Your backend reads those headers and uses the key to call the LLM

#

@severe vessel is this approach better ??

severe vessel
finite sky
#

Hi @severe vessel , I have completed the BYOK library update and pushed the latest code to my GitHub.

What I changed:

Implemented the callback-driven BYOK flow (frontend returns headers, backend reads them).
Removed proxy-style architecture so it stays as frontend + project backend only.
Added/updated docs and usage examples.
Cleaned the repo so it now contains only the library code.
I have already pushed the code to my GitHub.
Could you please tell me where you would like me to open the PR (which repository and branch)?

finite sky
#

@dapper warren Hey! can you please tell me where i should make a pr for this

dapper warren
finite sky
dapper warren
severe vessel
#

I have also invited you to a team that will give you access to write to this repo.

#

I had a quick look on the ReadMe. I suggest that you add screenshots of the widget to the readme.

finite sky
#

Hi @severe vessel , thanks a lot for the invite and for giving me write access to the repo. I’ve joined the team successfully.

I’ll update the README and add screenshots of the widget as you suggested so it’s clearer for others who want to use it.

Really appreciate the opportunity to contribute!

severe vessel
finite sky
#

Hey @severe vessel , I've opened the PR with the library code and updated README.
Could you please review when you get time