[brudgers]

The tool is completely free

Long term, how do you intend to sustain the service if users become dependent on it and need to use it at scale?

How do you intend to maintain reliability and uptime for users whose business depends on access to the service?

What happens to users if/when you lose interest/ability to continue the project?

Don't get me wrong, you don't owe other people anything. On the other hand, free is often a way of avoiding really hard (and very interesting) engineering problems. People are the hard part of engineering.

[lou_alcala]

I'm considering offering some additional features as paid options. Currently, the system only optimizes images from the URL you provide, but one potential premium feature could be to allow the system to crawl all internal pages of a website, optimizing images across the entire site. This would make it easier for users who want to optimize all their content by simply submitting the homepage URL.

However, this is a double-edged sword: I might encounter sites with a large number of internal pages, which would complicate the resources needed to provide an efficient and sustainable service.

Another option I've thought about is offering a CDN service to directly serve optimized images, improving performance without the need for users to manually download and upload images. It does become more complex when charging users, as reliability, support, and infrastructure take on a much greater role.

[jerriep]

You may also want to consider offering an API. I currently use (and pay for) the TinyPNG API.

[turtlebits]

If people aren't paying, none of those are problems. The second you charge, that's when the headaches come.

[jasonjmcghee]

"All images are deleted after 1 hour" - so they're using a server and it's a valid ask.

My question is - why does this require a server?

Write it in something that compiles to LLVM / WASM and just make a static page. Infinitely scalable and just pay for the domain (and CDN provider if applicable) both likely nominal cost.

[JTyQZSnP3cQGa8B]

Or why is it not a simple shell call to Imagemagick?

[kelvinjps10]

Then it needs a server

[solardev]

Not if you port the shell and OS and ImageMagick to WASM first!

[fuglede_]

ImageMagick in Wasm lets you do lots of nifty stuff client-side. Here's a photocopy simulation thingie I made for instance: https://photocopy.fuglede.dk/

[solardev]

That is fun indeed :) Good effect!

[aniviacat]

It can pull images from a domain. That would be difficult (since for client-side rendered sites it would require loading the site in a sandboxed environment) or impossible (if the site actively prevents that using CORS or similar, or if it happens to include scripts which expect to be run in a normal environment).

[siamese_puff]

There is also the ability to run things like Playwright on the edge a la Cloudflare Workers. You can fallback to rendering JS required sites through that and do clientside imagemagick WASM shenanigans on the client once the worker returns direct links to all the images.

[jasonjmcghee]

Yup totally fair - would likely require you upload the images manually for pure client-side.

You might still be able to offset a portion of the compute by just figuring out the URLs of the images on the back-end, sending that list to the client, which would then download and do the optimization / resizing.

[markdown]

> Write it in...

I look forward to your version of this service, also to be provided for free, right? And for your sake, hopefully you won't have people in the comments demanding that you completely redo your project in the special way that suits them.

[jasonjmcghee]

> Long term, how do you intend to sustain the service if users become dependent on it and need to use it at scale? ...

Is what I was responding to. Wasn't criticizing the posted product implementation choices or demanding a rewrite. I see how it could be read that way, which is unfortunate.

Parent comment asked a number of questions that all suggested a server was a requirement. If scale becomes any issue for a service like this, there are approaches other than shutting down the service due to server / maintenance costs.