feature-request: Use storyblok functions from this package directly on API routes

[chstappert]

Description

Can we import storyblok/nuxt directly on a nuxt API route instead of using the client? The setup is already done in the nuxt.config. Since the functions are only in the composable context, it would be nice to use them now on the API routes to get data and combine them with some logic.

Suggested solution or improvement

/* Use storyblok/nuxt package on a nuxt API route like this:  */

import { useStoryblokApi } from '@storyblok/nuxt' // and async functions

export default defineEventHandler(async (event) => {

const story = await useStoryblokApi().getStory('someStory') {...})

return story.data.story 

})

Additional context

I want to get data from storyblok, cache them with Nitro, and use the CMS data for our own (independent) endpoint to have consistent data and a clean setup.

Validations

• Follow our Code of Conduct

[alvarosabu]

Hi @chstappert thanks for reaching out.

So Vue composables are meant to work under a setup context, which means, inside components. Since server routes in Nuxt work with Nitro, I'm afraid composables won't work here.

An option would be to create a server utility for Nitro.

[steffkes]

I'd second that!

If you're trying to satisfy the requirement from nuxt's simple-sitemap to provide a list of dynamic urls - obviously based on what we have in storyblok, this little addition would be superb.

Otherwise we're doing the whole initialization again, potentially duplicating our config

[zacwebb]

I'm currently having to setup a separate instance of storyblok-js-client to make calls to the content delivery API from my server/api routes 😕 would be really nice to just use the Nuxt library exclusively

[freb97]

Hey,

The issue has been open for ~1.5 years, but IMO this feature should have a way higher priority. When using the module, the access key is exposed in the frontend which is a very bad practice. Every major Nuxt 3 module that handles some sort of API facilitation has nitro utilities to handle this.

Also, a server utility would give users more control about how they would like their data to be handled. Caching storyblok responses for example would be way easier if a nitro endpoint could just take care of it.

[alvarosabu]

Hi all, thanks for the feedback, maybe I can provide some context on why this feature isn't prioritized.

The issue has been open for ~1.5 years, but IMO this feature should have a way higher priority. When using the module, the access key is exposed in the frontend which is a very bad practice

I understand the concern but the accessToken is read-only:

Public and preview tokens are read-only and do not allow you or others to write or delete entries in a Storyblok space. The public token can safely be used in client-side code.

Rest assured, most of Storyblok websites operate like this. You don't need to worry about it.

Source https://www.storyblok.com/docs/api/content-delivery/v2/getting-started/authentication

I'm currently having to setup a separate instance of storyblok-js-client to make calls to the content delivery API from my server/api routes

Wouldn't that be mixing paradigms? If you make calls on the server you would be replacing doing:

// pages/index.vue

storyblokApi.get("/home")

to use your Nuxt API endpoint like this

// pages/index.vue

fetch("/api/home-endpoint")

So you no longer need the Storyblok JS instance at all in the client. If you go the server API routes way you are basically resigning the DX provided by the module, you have more control tho.

This doesn't mean we are not considering this feature to be included eventually, it just falls short vs other priorities in the ecosystem atm.

[alexjoverm]

Hey all, we just opened a PR that solves the need here. Feel free to re-open if you encounter any issues

#354