Interacting with AI from the Gutenberg Editor (and from other JS Applications)

I thin kif you use the openai module you should be ale to switch the backend calls pretty seamlessly.
I can imagine you don't want to rebuild the AI keys and connectors in the frontend so having them as an API seems obvious to me.
I'm not aware of plans of exposing them as generic API's at the moment.
there are some (specific) implementations that are not bound to a vendor and work with all ai providers.

- Check the controller for translations in ai_translate,
- check the controller for completion in ai_ckeditor
- there's a controller for image generation in ai_image

Having them as a separate module could make sense.
I'd call it ai_api, which you can then use in your frontends.
If someone built that I would consider switching those modules to use the generic one.

You could ask Marcus What the plans or ideas are since he's in the lead at the moment.

Thanks @wouters_f for your reply, the backend calls I have them in my API class itself:

src/Form/Plugin/rest/GutenbergAIEndoint.php

<?php

namespace Drupal\gutenberg_ai_tools\Plugin\rest\resource;

use Psr\Log\LoggerInterface;
use Drupal\rest\Plugin\ResourceBase;
use Drupal\rest\ResourceResponse;
use Drupal\Core\Language\LanguageDefault;
use Drupal\Core\Session\AccountInterface;
use Drupal\Core\Session\AccountProxyInterface;
use Drupal\Core\Entity\EntityStorageException;
use Drupal\Core\Entity\EntityTypeManagerInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException;
use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;
use Symfony\Component\HttpKernel\Exception\HttpException;
use Drupal\rest\ModifiedResourceResponse;
use Drupal\Core\Database\Connection;
use Drupal\Core\Config\ConfigFactoryInterface;
use Drupal\openai\OpenAIApi;

/**
 * Provides a Save Events User Endpoint
 * 
 * @RestResource(
 *   id = "gutenberg_ai_tools_openai_endpoint",
 *   label = @Translation("Gutenberg AI Tools OpenAI REST"),
 *   serialization_class = "",
 *   uri_paths = {
 *     "create" = "/gutenberg-ai-tools/openai-rest"
 *   }
 * )
 */
class GutenbergAIEndpoint extends ResourceBase {
.....

Feel free to open an issue if you want.

Hey danrod - this is a very good issue and I think something we can't afford to miss. There has been a move to having so much business logic in the frontend in recent years and with graphql/jsonapi etc, the backend mostly works as a rest api. Drupal has been in the forefront for this and I think it would be good if the same holds true for AI, for the people that wants to write their logic in the frontend.

I had a quick chat with wouters_f about this earlier and I think the best solution is that we create a standard complient OpenAI chat interface that can work with any AI provider and then also identify other provider leaders for other common operation types (e.g. Elevenlabs for text-to-speech).

If we can replicate this for the base functionality, that means you can use public libraries, but just point them at your local Drupal and then no more work is needed. We can setup so you have different permissions/providers per "apikey". That way it would be minimal work for anyone preferng to build most of the business logic in the frontend.

I think this is best if it lives in an external module, so any module that needs an api, could just require this one. I would be willing to help out with an initial skeleton/prototype version with permissions, none-streaming chat etc., but would need help from other maintainers for different type of providers at a later stage.

Thanks a lot for your input @marcus_johansson , I can help with adding OpenAI (and maybe other potential AI providers) and other work for your initial external module, I have quite some free time now.

Please let me know.

So the idea was basically to use the AI modules layer for this, so you don't have to add specific providers - then you can via the API choose to expose X amount of providers.

I'll get started on ai_api module and add the contrib module as soon as I have some prototype. It should only take some hours. You want to co-maintain danrod? Frederik as well?

Maybe AI Provider Gateway or AI Provider API makes more sense as a name? AI API is very generic, and could mean internal API's.

I'm ok with being the co-maintainer @marcus_johansson thanks !

First very rought version is here: https://www.drupal.org/project/ai_api → . Both you guys are full maintainers.

Check if the architecture makes sense. I think it should be flexible enough to work on all levels.

I think we can close this and continue on the issue queue under ai_log for all the errors/bugs/improvements we need there?

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