[feat]: support content-types from plugins

[laurenskling]

A clear and concise description of what the feature is

contentTypes in plugins are under /api/<pluginName>/<pluralName> :)

Why should this feature be included?

Because I like my contentTypes in plugins

Please provide an example for how this would work

const articles = sdk.collection('plugin::blog.articles');

[Convly]

Hey, thanks for the request!

Support for plugins' content-types is definitely something that needs to be addressed, nice catch!

However, I'm unsure about the proposed API/implementation, I'm trying to think about a solution that offers both:

• a good DX (avoid relying on raw strings)
• easy types' support in the future

For now, in the SDK, it's assumed that there is only one content type per API (based on plural/singular names), but for plugin we might need to reference an extra "source"

I'm wondering if something like sdk.collection('articles', { plugin: 'blog' }) would work/be more friendly than the raw string.

Happy to discuss it more, cc-ing @jhoward1994 and @maccomaccomaccomacco

[laurenskling]

I just used the syntax that you'd use within Strapi. f.e. strapi.contentType('plugin::blog.articles'); or strapi.service('plugin::blog.articles');.

[jhoward1994]

I like this idea @Convly

sdk.collection('articles', { plugin: 'blog' })

For core content types we don't provide the SDK full UID's of content types but instead plural names. If we can keep that consistent when interacting with plugins it would be good.

cc @maccomaccomaccomacco

[alexandrebodin]

Plugin content-types don't have core API endpoints by default there is not endpoint we can consider will always exist for a plugin. We cannot offer such capabilities on the content API

[laurenskling]

True, the core endpoints are not created by default. But if you follow any documentation, you will create a coreController and coreService for your contentType yourself. But yeah, a check if there are actually routes registered would be helpful. And routes are not limited to the convention at all, so could be whatever.

Maybe thinking outside of the box; what if we make a marker on the contentType, stating that it follows conventions and is supported by the SDK?
Something like:

  options: {
    draftAndPublish: true,
    privateAttributes: [],
    sdk: true,
  },

Because for example users-permissions is definitely not SDK proof, but it's very easy to create something that is. https://github.com/gatsby-uc/plugins/tree/main/packages/gatsby-source-strapi also assumes plugin contentTypes to be the same as api contentTypes and it works just fine.

[alexandrebodin]

We have mutliple options to explore

• sdk extension (you register let's say the u&p extension of the sdk so it exposes the right API via sdk.plugin('pluginName').login/.... This is the best in terms of DX but requires extra work for plugin devs to also build an sdk extension
• Everything around generation of the sdk which is coming so we can also generate plugin endopoint directly
• some Programmatic apis with less safety (we can't guarantee the route exists etc) that would just try to call the core api. we just don't have the route path so we need some extra infos

[laurenskling]

For me personally, just trying core api's and having a good error, stating that it failed and you ran it with plugin:.. so it's probably not supported, would be good enough. Plugins that work, work. Plugins that don't, crash with a good message. Fine for a first version. Maintaining a sdk extension sounds like error-prone extra labour. Probably good for someting big as u&p, but not for simple normal content.

[jhoward1994]

Maybe we could handle this as an extension to strapi/strapi#22689

• Firstly we could add a CLI argument to include plugin UIDs. Either by accepting UID prefixes or including all plugin UIDs

  • Initially this could assume the core APIs exist as you mentioned & error out when they don't

• We could extend this further to understand the routes that exist for each plugin content type and provide that in the generated types

?

[Convly]

In my opinion, we could start very simple by allowing passing a { plugin: 'foo' } param to the collection and single type manager, then assume the endpoints exists and try to query them. We can then get creative with error messages and handling.

In a second phase we could leverage the generated SDK schema to serve prog API like .plugin('users-permissions').register() or .plugin('upload').upload()

What do you think?

[alexandrebodin]

In my opinion, we could start very simple by allowing passing a { plugin: 'foo' } param to the collection and single type manager, then assume the endpoints exists and try to query them. We can then get creative with error messages and handling.

In a second phase we could leverage the generated SDK schema to serve prog API like .plugin('users-permissions').register() or .plugin('upload').upload()

What do you think?

how will you determine the routes though ? /pluginName/name ?

[Convly]

In my opinion, we could start very simple by allowing passing a { plugin: 'foo' } param to the collection and single type manager, then assume the endpoints exists and try to query them. We can then get creative with error messages and handling.
In a second phase we could leverage the generated SDK schema to serve prog API like .plugin('users-permissions').register() or .plugin('upload').upload()
What do you think?

how will you determine the routes though ? /pluginName/name ?

Yeah that's a good point. I was playing with generated API for plugins and couldn't figure out what would be the best way of doing it.

Maybe this needs to wait for the generated prog API? 🤔

Another option could be to use a plugin('<xxx>') factory that would return an object exposing its own fetch client (pointing already at the plugin root path in the content-api). It wouldn't create the shorthands we have for API collection and single types, but would still improve the plugin DX.

What do you all think?

[jhoward1994]

plugin('<xxx>').fetch could be a nice first step to give something useful prior to the generated API

Do you think the generated API will follow the same structure? e.g. I think if we go this way plugin('xxx') should always be the way to start plugin interactions for consistent DX

[alexandrebodin]

I'm not sure I see the point of the plugin(xx).fetch ? just adding a prefix to the url ? simple example put u&p doesn't have API prefixes for ex.

what about offering configuration for single & collection fns ?

single('plugin:xxx.xxx, { path: '/plugin-route' }) this would also work for non plugin ones as devs can also change the path for their own apis 🤔