Out of video streaming minutes on Free plan results in GraphQL error

[jesper]

I am building a new site for a client. While developing its running on the Free plan and it just ran out of video streaming minutes. This now results in a GraphQL error when querying the “video” field: "Cannot return null for non-nullable field VideoFileField.video"

IMO this is a bad developer experience as it makes further development quite complicated. Sure, we can go ahead and remove all occurrences of video in queries, but then we have to remember to add them back etc.
IMO the whole query should not fail and error. You can just return “null” for the video field.

My query is like this:

  fragment VideoFragment on UploadVideoField {
    muxPlaybackId
    title
    width
    height
    blurUpThumb
  }

fragment BlogPost on BlogPostRecord {
  title
  featuredVideo {
    video {
      ... VideoFragment
    }
  }
}

What I have found:

The same query is possible when testing on the “Content Delivery API Playground” online.
It appears there is a difference in the schema though. See these two screenshots:

Playground:

Query with gql.tada in VS Code:

The gql.tada query says UploadVideoField is required (with the “!” mark) but the Playground does not.

My project is based on the “starter kit” here: GitHub - datocms/nextjs-starter-kit

Any suggestions?

[roger]

Hi @jesper,

Unfortunately, our free plan isn’t really designed for production use By design, it will cease to function once you hit the limits, whether it’s streaming minutes or any of the other ones (from Pricing — DatoCMS):

These will reset next month.

2 hours of streaming should be a lot for development, no? Is there a reason you need to test that much video during dev, before the site’s live? If this is an exceptional circumstance, could you please email us with some details at support@datocms.com with your project details, and I’ll ask the devs if there’s anything we can do for you.

Or, are you perhaps on an older free developer plan that had different limits? (We’ve changed them through the years, just in case you’re still on a grandfathered account. You can check that and change plans in your personal dashboard, if necessary.)

---

If the video limit is the only thing that’s holding you back, of course the easiest option is to just upgrade to paid plan, and the limits will be lifted automatically (takes an hour or so, I think?). If that’s not a possibility, you can also serve the raw MP4 URLs (generally not recommended: see explanation here, but might be a workaround in the meantime), or cache/proxy them elsewhere (like your frontend host or Mux directly or Vimeo, Cloudflare Streaming, YouTube, etc.).

Alternatively, if you regularly use DatoCMS on behalf of clients, I should also mention our free Partner program, which gets you and your clients discounted monthly plans (and because they are are still paid plans, that’d also remove the hard overage blocks).

---

I hope some of those possibilities help a bit. Sorry, at the end of the day, the free plan is limited by design (we have to get paid somehow ) and that probably won’t change. Even if it’s not the streaming video, other limits will eventually be reached and error out in their own way. The only way to avoid the blocks altogether is to either upgrade to a paid plan or else use so little resources (e.g. via caching/proxying) that you don’t hit the limits.

Sorry, I know that’s not what’s you wanted to hear Just trying to explain the situation a bit.

[jesper]

Hi Roger, thanks for answering.

I totally understand the limits of the Free plan and of course you have to make money. No issues with that, no worries.

My initial post might have come out wrong. The real issue is that my GraphQL query requesting a video fails with an error on my client/Next.js app, but it does not in the API Playground. Why is that?

As you can see in these two screenshots, the schema generated using gql.tada generate schema https://graphql.datocms.com --header [.....] is different from the API Playground.
The UploadVideoField is required/not-nullable on the gql schema file, but optional in the API Playground.

Schema:

Playground:

There is no exclamation mark in the API Playground field type.

So why is that?

You can easily reproduce the issue by cloning GitHub - datocms/nextjs-starter-kit , make a “Free plan” account and max out on the video streaming limit, and then create a model (call itBlogPost) that has “Media > Single Asset” field (call it featured_video) expecting a video file:

Create the record for the model and add a video file to the field.

Now use this query in the API Playground:

fragment VideoFragment on UploadVideoField {
  muxPlaybackId
  title
  width
  height
  blurUpThumb
}

query BlogPostQuery {
  blogPost {
    featuredVideo {
      video {
        ... VideoFragment
      }
    }
  }
}

This will resolve without errors and returns:

{
  "data": {
    "blogPost": {
      "featuredVideo": {
        "video": null
      }
    }
  }
}

However if you do the same query in your Next.js app using the starter kit (after you have auto-generated the schema, so that you can query the model and field etc.) then the exact same query will error with this:
"Cannot return null for non-nullable field VideoFileField.video"

THAT is the issue.

Sorry I was not clear about that in my first post

Does it make sense? And do you know why this happens?

Thank you!

[roger]

Ah, @jesper, so sorry for misunderstanding your first post! I got you now.

That’s more to do with your GraphQL fetch call settings than your free plan, I think. Specifically this line in the demo project: nextjs-starter-kit/src/lib/datocms/executeQuery.ts at main · datocms/nextjs-starter-kit · GitHub

We call it “strict mode” and apparently it’s enabled by default for the Next.js demo, but not the playground. You can manually set it using the excludeInvalid option in our JS CDA client, or the X-Exclude-Invalid HTTP header: API endpoint and header modes — Content Delivery API — DatoCMS

Does that help at all? Sorry about my earlier confusion!

[jesper]

You are right, the “exclude invalid records” did the trick. Thank you, Roger.