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!

[walterdf]

I would like to propose an idea that I believe would be highly beneficial for our Carbon Now project: enabling it to run locally and making it open source. Below are several reasons why I consider this change advantageous:

Ease of Development and Testing:

Local Development: Allowing the project to run locally provides a more accessible and convenient environment for developers to perform tests and rapid implementations. This accelerates the development cycle and makes it easier to identify and fix bugs.

Increased Community Collaboration:

Open Source: Making the project open source opens the doors to the global developer community. This not only brings new ideas and improvements to the project but also increases the base of contributors who can help maintain and expand Carbon Now.

Transparency and Trust:

Transparency: Open source projects are inherently transparent, which builds more trust among users and contributors. Transparency in development and technical decisions strengthens the relationship with the community and ensures that the project follows best practices.

Greater Flexibility:

Customization: By allowing the project to run locally, we offer greater flexibility for each developer to adjust and customize the project according to their specific needs, without relying on centralized infrastructure.

Accelerated Innovation:

External Contributions: The open source community is known for its ability to innovate quickly. By opening the project, we can benefit from external contributions, continuous improvements, and new features that would be difficult to achieve otherwise.

Cost Reduction:

Infrastructure: Allowing the project to run locally reduces dependence on centralized infrastructure, which can result in significant savings on operational costs.

Additionally, it is worth noting that other projects with similar characteristics are emerging. This places our project in check, as it risks becoming outdated or less competitive if we do not adapt to these new trends.

I firmly believe that enabling Carbon Now to run locally and making it open source will bring many benefits not only to our team but also to the global developer community. I am available to discuss more details and assist in implementing this proposal.