While the current documentation provides a good overview of how to create a third-party provider, I believe there are opportunities for improvement. Specifically:

  • When creating a third-party provider, in addition to the plugin implementation, it is important to cover the setup of the configuration form and schema.
  • The concept of API defaults, which defines the configuration parameters for the provider (e.g., max tokens, temperature), should be explained in more detail.
  • It would be helpful to include best practices for API client retrieval, particularly regarding the use of methods like getClient() and loadClient().
  • I also suggest adding separate sub-sections for each operation type in the future, but I recommend creating a separate issue for that enhancement once these improvements are addressed.

As I already have some experience with implementing Gemini Provider, I can propose this changes for review.

Issue fork ai-3476719

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

jibla created an issue. See original summary.

jibla’s picture

Issue summary: View changes

jibla’s picture

Status: Active » Needs review
mrdalesmith’s picture

Status: Needs review » Needs work

This MR is 148 commits behind the upstream repository, and adds an AI Provider within the AI module structure: AI Providers should now be separate projects of their own (see https://www.drupal.org/project/openai as an example) and all the providers within the codebase are deprecated.

I think this should be reworked to meet the issue raised (improve documentation) and remove any changes not related to that (implementing a new provider).

jibla’s picture

Thank you for the feedback @mrdalesmith

The dropai_provider included, is not actually a provider, but an example module for the fictional provider explained in the documentation and the files are linked there. My motivation was that ic can help other developers and can be used as a starter code to build new providers.

Alternatively, I can create a separate project and put that module there.

jibla’s picture

Status: Needs work » Needs review
marcus_johansson’s picture

Status: Needs review » Needs work

Hi Giorgi - thank you for the documentation. As @mrdalesmith writes, we should not have it in visible modules directory. The providers and vdb_providers folders will be removed completely before the prod version is released.

if we want an example module, I think you can put it under docs/examples.

Another option is under tests/modules - we already have a provider module there for testing, but having one to showcase how it works as well would be all ok. I've seen that's how they do things with Experience Builder as well.

You should also add "hidden: true" in the info.yml just to make sure it doesn't show up, but modules under tests or docs should not show up anyway.

jibla’s picture

@marcus_johansson @mrdalesmith

Thanks, it makes sense- moved module under docs/examples.

jibla’s picture

Status: Needs work » Needs review
mrdalesmith’s picture

Status: Needs review » Needs work

Your branch is still way behind so the tests aren't running: you need to update the fork and rebase your branch so this can be reviewed properly.

jibla’s picture

Status: Needs work » Needs review

marcus_johansson’s picture

Status: Needs review » Fixed

Thank you Giorgi, merged.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

kristen pol’s picture

Title: Improve Documentation for Creating Third-Party Providers » Improve AI Documentation for Creating Third-Party Providers
Assigned: jibla » Unassigned