offline support: run without needing to contact carbon server

[jokeyrhyme]

I'm wondering whether this is possible / desirable to be able to run this tool locally in an offline way?
Is this outside the scope of this project? Or would a PR be welcome?

[mixn]

@jokeyrhyme Thanks for your feedback. :)

While this should be possible, I don’t know how desirable or needed it really is, to be honest. It’d have to locally co-exist with the entire Carbon project, and carbon-now-cli is already quite big as is, mostly due to the usage of Puppeteer. It’d also assumingly add quite some waiting time before being ready and some (I think decent) amount of work to make it all happen for — in my opinion — quite an edge case.

Of course, this is just my opinion. :) I’d be curious to know more about the why’s of your idea.

TL;DR: I do rather feel like this is outside of the scope of this project.

[jokeyrhyme]

@mixn teehee
I didn't realise this CLI uses puppeteer to drive the remote carbon service, which itself internally uses puppeteer to render the code with canvas within a browser
I think this is the main rendering logic within carbon: https://github.com/dawnlabs/carbon/blob/master/handlers/image.js
This makes me wonder whether we could copy that into the CLI, which is already using puppeteer...

[jokeyrhyme]

@mixn in terms of use cases, I just prefer things to be offline whenever there's no special reason for them to require a connection
People don't always have a connection available, and people might not always be comfortable sending their code to a remote service

[mittalyashu]

People might not always be comfortable sending their code to a remote service.

Agree with this.

[jwkicklighter]

One way you could accomplish this is to setup carbon to run locally (or on your on server) and then add some config to this CLI that sets what remote server to use. Certainly not as nice as bundling everything, but an alternative that requires less from this project.

[mixn]

All technical things aside, I feel like all of this would be “taking away” from the hard work Dawn Labs have put into Carbon. This CLI should not “avoid” the service, but co-exist with it — since it wouldn’t exist without it in the first place. :)

[aibolik]

I think in the scope of this project it should leave as is.

Carbon is awesome, but I think it was supposed to use the website and mainly with gists. So, probably it is reasonable to think about another CLI library that does what carbon does without any internet connection, since it can be done(and it is what actually all famous IDEs do).

Internet connection can be used for fetching themes, additional plugins or/and gists, if you want to build image from gist.

I think that will be interesting challenge/project :)

[mixn]

I’ve re-opened this issue, hoping that some people might chime in… 🤞

I’m currently finalizing the big #83 release, and although I was initially planning on implementing this, then decided against it, now I’m totally unsure once again. 😕

1. I believe that carbon-now-cli should co-exist with the tool it is wrapping. Carbon also generates revenue through ads, and I do not want to take away from that revenue by enabling users to run carbon-now-cli offline.

2. If I were to enable carbon-now-cli to run offline, I would need to bundle the entirety of Carbon as a binary and ship it with the CLI. This would mean that I would have to make a new release whenever Carbon ships new features, which is not an efficient process and something I want to do.
   The only way I’d consider doing it is the one described by @jwkicklighter, which I quite like.

3. I have chatted with Mike from the core team of Carbon, and he has confirmed that the way I am consuming Carbon is the right and best way (as there is no official API + this gives you the most flexibility). It is important to follow his guidance, as he best understands Carbon and its current capabilities.

Long story short, I’ll leave this open, hoping that the conversation will spark up again and more of you will chime in. 🙂

Thanks for reading and caring!

[iHiD]

Hello 👋

We're building out some automatic just-in-time image generation for OpenGraph images at Exercism and I was planning on using Carbon to achieve this (to the point of having it dark-deployed). I only just realised that it doesn't work in a self-contained manner and that's a definite downside for us (maybe a show-stopper).

There's a few reasons it's bad for us:

1. It makes Carbon's website a dependency. If they have ops issues, we have ops issues, etc. We're limited by their performance, etc
2. It means we're going to be sending millions of images for them to render, which they'd probably rather not have to bare the cost or hassle of. If we do batch-processing on older solutions for example, that's us throwing an extra 30 million jobs in an hour at them for example, which isn't very nice.
3. We have to run this code in a internet-facing environment, not a private, secure one.

Right now, my plan would be just to deploy our own version of carbon.sh and point this at that instead of the carbon website, or just write our own version of the whole thing instead (I'm probably leaning towards that at the moment as we already do code highlighting etc in our codebase) but a bundled version would be the easiest and nicest approach. That's my feedback :)

[lukesalamone]

There's a few reasons it's bad for us:

1. It makes Carbon's website a dependency. If they have ops issues, we have ops issues, etc. We're limited by their performance, etc
2. It means we're going to be sending millions of images for them to render, which they'd probably rather not have to bare the cost or hassle of. If we do batch-processing on older solutions for example, that's us throwing an extra 30 million jobs in an hour at them for example, which isn't very nice.
3. We have to run this code in a internet-facing environment, not a private, secure one.

@iHiD These were issues for me as well, and I didn't like the unnecessary privacy risks of sending my code over the wire to accomplish something so simple. Carbon has nice features but ultimately I just need to add text to an image. That's why I built out my own local-first solution called Nitro: https://github.com/lukesalamone/code_nitro

[QAbot-zh]

@lukesalamone
Good job! I have also been trying to develop my own local-first solution, but I lack experience in color-matching and aesthetics. Your work has basically met my goals. Thank you!