Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

offline support: run without needing to contact carbon server #15

Open
jokeyrhyme opened this issue Jul 12, 2018 · 11 comments
Open

offline support: run without needing to contact carbon server #15

jokeyrhyme opened this issue Jul 12, 2018 · 11 comments
Labels
feature-request New feature or request feedback-needed Feedback is needed

Comments

@jokeyrhyme
Copy link

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 mixn added the question Further information is requested label Jul 13, 2018
@mixn
Copy link
Owner

mixn commented Jul 13, 2018

@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
Copy link
Author

@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
Copy link
Author

@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
Copy link

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

Agree with this.

@jokeyrhyme jokeyrhyme changed the title offline support: bundle and run the carbon server locally? offline support: run without needing to contact carbon server Jul 13, 2018
@jwkicklighter
Copy link

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
Copy link
Owner

mixn commented Jul 20, 2018

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
Copy link

aibolik commented Jul 25, 2018

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 mixn closed this as completed Aug 2, 2018
@mixn mixn mentioned this issue Feb 6, 2023
26 tasks
@mixn mixn reopened this May 9, 2023
@mixn mixn added feature-request New feature or request v2 labels May 9, 2023
@mixn
Copy link
Owner

mixn commented May 9, 2023

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!

@mixn mixn added feedback-needed Feedback is needed and removed question Further information is requested labels May 10, 2023
@mixn mixn removed the v2 label May 23, 2023
@iHiD
Copy link

iHiD commented Aug 14, 2023

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
Copy link

lukesalamone commented Aug 16, 2023

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
Copy link

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request New feature or request feedback-needed Feedback is needed
Projects
None yet
Development

No branches or pull requests

8 participants