Improve Documentation for Creating Third-Party Providers

Created on 25 September 2024, 7 months ago

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.

📌 Task
Status

Active

Version

1.0

Component

Documentation

Created by

🇬🇪Georgia jibla

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @jibla
  • Pipeline finished with Failed
    5 months ago
    Total: 141s
    #351944
  • 🇬🇧United Kingdom MrDaleSmith

    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).

  • 🇬🇪Georgia jibla

    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.

  • 🇩🇪Germany marcus_johansson

    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.

  • 🇬🇪Georgia jibla

    @marcus_johansson @mrdalesmith

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

  • Pipeline finished with Failed
    5 months ago
    Total: 172s
    #354117
  • 🇬🇧United Kingdom MrDaleSmith

    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.

  • Pipeline finished with Failed
    5 months ago
    Total: 154s
    #356345
  • Pipeline finished with Failed
    5 months ago
    Total: 159s
    #356420
  • Pipeline finished with Failed
    5 months ago
    Total: 141s
    #356426
  • Pipeline finished with Success
    5 months ago
    Total: 169s
    #360254
  • Pipeline finished with Success
    5 months ago
    Total: 180s
    #370867
  • 🇩🇪Germany marcus_johansson

    Thank you Giorgi, merged.

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

Production build 0.71.5 2024