Open JanThiel opened 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.
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
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.
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 ).
Just as a note: The fork is running fine on Vercel and Cloudflare Pages.
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
@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 :-)
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
? :)
@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.
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.
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!
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 :-)