chargebee / chargebee-typescript

Typescript library for the Chargebee API.
https://apidocs.chargebee.com/docs/api?lang=typescript
MIT License
22 stars 16 forks source link

[feature request] NextJS Edge Runtime Support #50

Open JanThiel opened 5 months ago

JanThiel commented 5 months ago

Hey there,

in the modern times the "Edge" runtime gets more and more attention. It is a subset of the NodeJS API which makes it faster and more suitable for "Cloud Hosting" services like Vercel or Cloudflare Pages. In particular when building NextJS apps.

As hosting a custom Chargebee Portal / Checkout on one of the aforementioned services in combination with a NextJS app is quite a powerful approach, I would like to ask whether you are willing to make this library "Edge" compatible. There should only be some places where you have to switch packages or only use them conditionally.

There is this nice guide which explains the benefits of offering Edge support: https://vercel.com/guides/library-sdk-compatible-with-vercel-edge-runtime-and-functions

And some more compare-charts-docs explaining the Edge runtime compared to full NodeJS: https://nextjs.org/docs/app/building-your-application/rendering/edge-and-nodejs-runtimes

And finally the Edge Runtime - as in "all the supported APIs" - for NextJS is documented here: https://nextjs.org/docs/app/api-reference/edge

Based on our current development the one problematic place is this: https://github.com/chargebee/chargebee-typescript/blob/2bc591b8abeeef17b42a012167c9e9d8cabeaf54/src/core.ts#L8

And it is just used for information Metadata... So not really necessary at all.

Thank you for reading and considering :-)

cb-sriramthiagarajan commented 5 months ago

Hey @JanThiel,

Thanks a lot for the detailed notes. Yes, we're considering making the SDK Edge compatible but we don't have a solid timeline for this yet unfortunately.

I will share updates here when we have more details & timeline for this.

JanThiel commented 5 months ago

Hey @cb-sriramthiagarajan,

Thanks for your feedback.

From our current knowledge the os module is the only one preventing and Edge deployment. Will let you know once we have the app deployed.

We will use a fork of the library till you have some official release.

Best,

Jan

JanThiel commented 4 months ago

It would have been to easy ;-) Further digging in, there - naturally - is more in the way to go...

http, https and the q module all are incompatible with Edge Runtime. The first two can easily be replaced by using fetch.

q uses setImmediate which is NodeJS only. Just FYI.

JanThiel commented 4 months ago

Got that sorted out as well.

tldr: You have to raise the Min NodeJS Version of the package to 18.

Then you can use fetch instead of the http and https modules. The q library is obsolete as well, as you can use native Promises.

But to have the native web libraries in NodeJS version 18 is required. fetch is only part of Node since then.

You can find the changes - based on chargebee-node on our Fork ( https://github.com/Hive-IT-GmbH/chargebee-node ).

JanThiel commented 3 months ago

Just as a note: The fork is running fine on Vercel and Cloudflare Pages.

cb-sriramthiagarajan commented 20 hours ago

Hi @JanThiel, we have released a new beta version that supports Edge Runtime and will eventually be the single package to integrate Chargebee using JavaScript/TypeScript. It'd be great if you could try it and share your feedback.

You can install this using npm install chargebee@beta

JanThiel commented 17 hours ago

@cb-sriramthiagarajan Thank you very much for the update and your work. Looks like a massive improvement to me. Replaced the old version with the new one. Tested on Cloudflare Pages. Works well :-)

cb-sriramthiagarajan commented 16 hours ago

That's great @JanThiel! Thanks for checking this quickly.

How much is your fork diverged from upstream? I wonder how easy / difficult would it be to switch from your fork to this package once we're out of beta? :)

JanThiel commented 14 hours ago

@cb-sriramthiagarajan I would say it's a straightforward task. Nothing complex nor surprising. The code gets cleaner. So there is a real benefit in migrating to 3.0. But still you have to change all library calls. I would say 3.0 is as close to a drop-in replacement for 2.x as you can come while solving the problems of the 2.x library foundations.

The most remarkable changes we encountered while migrating:

New Import

- import chargebee from "chargebee";
+ import Chargebee from "chargebee";

Setup as Object instantiation

- chargebee.configure({
-    site: process.env.CHARGEBEE_SITE,
-    api_key: process.env.CHARGEBEE_API_KEY
- });

+ const chargebee = new Chargebee({
+     site: process.env.CHARGEBEE_SITE,
+     apiKey: process.env.CHARGEBEE_API_KEY
+ });

Removal of the need to call .request()

- const subscription = await chargebee.subscription.retrieve(params.id).request();
+ const subscription = await chargebee.subscription.retrieve(params.id);

Typings are now much better and autocomplete as well. Naturally. In general it feels much better to work with 3.0 than the current lib version.

JanThiel commented 14 hours ago

How much is your fork diverged from upstream?

Close to none, Just patched the base library. Nothing changed that has any impact on the usage of the library. As such I simply merged your upstream changes into it with no issues.

cb-sriramthiagarajan commented 11 hours ago

Awesome, you captured the major changes accurately @JanThiel 😄

I forgot to mention that we have a Migration guide for v3 and the README in the next branch also has more info on the usage.

Close to none, Just patched the base library. Nothing changed that has any impact on the usage of the library. As such I simply merged your upstream changes into it with no issues.

That's great to hear! We'll be testing this with a few customers to see if there are any issues before we publish this as the latest version. It'd be great if you could test this version in your test / staging environment and report any issues that you encounter. Thanks!