Improve Documentation for Creating Third-Party Providers

Created on 25 September 2024, 3 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
  • 🇬🇪Georgia jibla
  • 🇬🇪Georgia jibla
  • Pipeline finished with Failed
    23 days 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.

  • 🇬🇪Georgia jibla
  • 🇩🇪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.

  • 🇬🇪Georgia jibla
  • Pipeline finished with Failed
    22 days 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
    19 days ago
    Total: 154s
    #356345
  • Pipeline finished with Failed
    18 days ago
    Total: 159s
    #356420
  • Pipeline finished with Failed
    18 days ago
    Total: 141s
    #356426
  • Pipeline finished with Success
    15 days ago
    Total: 169s
    #360254
  • 🇬🇪Georgia jibla
  • Pipeline finished with Success
    4 days ago
    Total: 180s
    #370867
  • 🇩🇪Germany marcus_johansson

    Thank you Giorgi, merged.

Production build 0.71.5 2024