Bannerbear.com can help you there - we generate PNGs / PDFs based on data you send us either via API or Zapier. Would be very simple to set up what you're describing :)
I'm the 2nd example in the post (Bannerbear.com) and I wasn't in a full time job when I started it. There was definitely a feeling of existential motivation...
So we need to do more than one thing, this helps us choose one thing and focus on it, then when we want to do something else, we do more than one thing again, and choose another one thing to focus on.
Very wise. It gives us a specific order of doing things. Many things, then one thing, then many things, then one thing. I was kinda doing the opposite.
I was completely lost with AWS lambda until I discovered https://serverless.com - the fact that you haven't found them yourself suggests they need to do a much better job of marketing themselves!
I run my lambdas locally with a single command: serverless offline
If the lambda has an http endpoint, it creates the endpoint at localhost/<endpoint> and I'm good to go, it even does live reloading as I edit my code.
If the lambda runs off AWS events, I can invoke the lambda locally with a command, and point it to a JSON file of a simulated AWS event. I get my local rails app to create these AWS event JSON files, so that I can test end to end locally. Works well for my purposes.
To deploy I just run: serverless deploy --stage production
Which sets up all the necessary additional services like API Gateway, cloudwatch etc.
+1 -- yes if you must develop AWS lambda, then serverless is the BEST way.
BUT .. I should also say that while I started ~5 years ago with serverless framework, in the past year I've completely transitioned everything over to the Azure Durable Serverless Functions.
AZ has their own same-same-but-better "Core Functions Power Tools", it's got a lovely & zippy cli interface built in node that is separate/decoupled from the "az cli". Just like serverless you can run/dev/test locally, then quickly deploy to azure. The debugging integration with VS code, distributed tracing, even "AZ Remote Debugging" with "Azure Hybrid Connections" creates super fast inner/outer development loops.
If you like the "serverless model" then you also need to check-out AZ "Logic Apps". Logic custom connectors totally kick ass imho since they provide a ton of insight into how data is moving through the application, basically you deploy and you get instantaneous telemetry.
Deploying software that costs nothing (except negligible storage fees) unless you're using it AND would require an ELE (i.e. meteor strike) to break is very cool.
Funnily enough it costs more in fees for me to use Wise as my daily account so I've kept my traditional bank cards! I do suspect it varies by country. I'm fortunate in New Zealand that banks generally offer fee-free accounts with reasonable terms and conditions.
- daily spending on goods and services
- electronic transfers to ewallets*
- any time someone needs to send me money, I use transferwise virtual account details so from their end it seems like a domestic transfer
- I even bought a motorcycle using Transferwise to do a local bank transfer. Tried it with my regular (foreign) bank first and it failed, tried it with Transferwise and it worked fine.
*my traditional bank doesn't support this. They only know how to deposit to a domestic ewallet, Transferwise can do deposits in ewallets internationally
I use it as my primary spending debit card. I travel a lot, use it in random ATMs and I keep it topped up just enough that I wouldn't be devastated if the account contents were stolen. Also use the money transfer side monthly to pay rent in a foreign country.
For people who are on the trial and need more quota, I simply tell them they are welcome to create 2nd, 3rd etc accounts. I have no issue with that.
"How much free quota" to give is a question with no right answer. So instead of forever trying to tweak that number, I have left it at an amount that seems to be working and I don't increase it for anyone (I have not even built in the ability to extend a free trial).
There's still a lot to be optimized on the video side of things. But the reason it took 2 minutes is because of things like:
- Checking the video length before rendering
- Converting to a standardized format so that the renderer doesn't trip up
- Handing off to AWS Lambda, which involves some network I/O
- Handing back to my Rails app
So there's a lot of back-and-forth right now that could be optimized.
It will scale nicely under high workloads because my main Rails app isn't really doing much except handing off to AWS Lambda, but this means there is a speed hit both in terms of the I/O and also the Lambda being underpowered.
You can actually see the two main processes happening if you watch the progress bar on the video demo.
You'll notice that the first 50% is a bit slow - that's my Rails app doing some validations, conversions, and packaging things up nicely for the Lambda.
The last 50% seems to move faster - that's the Lambda rendering the final video and then passing it back to Rails.
There's definitely a lot of scope for speeding things up in the first 50%.
As for disrupting long-running processes, I can safely deploy my Rails app any time as it's not performing any of the rendering jobs (on images or video) it's just acting as the job expeditor and receiver of webhooks.
I agree with you, automated open graph images are not a problem worth paying lots of money to solve. That's pretty much the exact realisation I had at the mid point in this timeline - see the "Rebrand" section for the details.
So at that point I pivoted Bannerbear to be able to generate any kind of image, for any purpose.
New use cases are things like, generating ad variations, generating instagram posts, generating dynamic in-app images (e.g. in the welcome email for Bannerbear you get a personalized image header which is generated on-the-fly by Bannerbear) and these use cases are a lot more valuable to the end users.
Basically anyone who needs to do repetitive image generation.
The idea came from when I was working in Ecommerce. We would be uploading anywhere from 5 to 50 new products to our store every day. And those products would have multiple photos (different angle views). And from those different views, we would be manually creating all sorts of marketing assets e.g. ads, social media posts etc.
On top of the image, we would usually want to overlay things like our logo, or a coupon code, or the product name etc. All of this stuff was done manually and it was a PITA.
So my product is aimed at two types of customer,
1) the above type of user who needs some kind of highly-scalable and flexible banner generation API. Digital ad agencies, ecommerce stores.
2) a lower volume type of customer who wants to do the same but at a smaller scale, maybe for their own solo business. These customers use Zapier to integrate with Bannerbear, rather than using the API directly.
Bannerbear.com can help you there - we generate PNGs / PDFs based on data you send us either via API or Zapier. Would be very simple to set up what you're describing :)
Some tutorials to browse: https://www.bannerbear.com/resources/nocode/tutorials/