feat: rewrite using Next.js api routes

[nico-bachner]

Apologies in advance — this is a big one.

I completely rewrote the project using Next.js API Routes and also converted the homepage to use Next.

There most important thing to be aware of is that there are breaking changes. First, the endpoint is now at /api/[file], no longer at /[file]. Also, many of the query parameters have changed.
If these changes are inconvenient (backwards compatibility), I will be happy to review the PR and minimise the api changes.

Demo here: https://og-image-nine-nu.vercel.app

Additional note: this PR is not ready to merge yet because of an issue with puppeteer in production.

[vercel]

@nico-bachner is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[styfle]

Thanks for the PR!

This looks really cool!

However, we can't accept breaking changes to the API at this time since its referenced by https://vercel.com/docs

[nico-bachner]

Thanks for the PR!

This looks really cool!

However, we can't accept breaking changes to the API at this time since its referenced by https://vercel.com/docs

I thought that might be the case.

If you like, I can try and eliminate the breaking changes.

I can also offer another solution: since the api endpoint in this PR is at /api/[file] (as per Next.js conventions), and the endpoint currently is at /[file], it should be possible to have both coexist at the same time (this would give people the option between v1 and v2).

What do you think?

[styfle]

You can avoid the breaking change by adding rewrites to next.config.js

{
  rewrites: [{ source: '(.*)', destination: '/api']
}

[nico-bachner]

It can be solved by adding “rewrites” to next.config.js

Which part of the issue do you mean by that?

[aguilaair]

Which part of the issue do you mean by that?

Sorry for chiming is after such a long time, but I believe he means that by using rewrites you could make it backwards compatible as api path would be removed. This effectively redirects anything that fits the regex (.*) to /api behind the scenes.

[nico-bachner]

Thanks @aguilaair for the explanation, but that part was clear to me. The breaking changes I am worried about are caused by my implementation being ever so slightly different from the original, which could potentially break existing users' URLs.

What I was suggesting to @styfle was that if we don't use redirects, then the two versions of the api could potentially coexist on the same domain, however after some experimentation, I realised it would be best to just stick to the original api.

[styfle]

Closing in favor of #226