I am trying to build apps that use little to no backend, but there are times when I need one. Not for auth/storage, but for business logic.
Some examples I can think of right now are:
In my read-it-later app, I need to bypass CORS to download images, which is not possible to do in browser. So I made a cloudflare worker thats just a basic http proxy. You can see how the user can specify the location to that worker here: https://savr.link/prefs
In another app I’m building with a messaging system (GitHub - jonocodes/LinkHop: Send messages and urls between your browsers/devices · GitHub), I am experimenting with how to give a more realtime push experience to my remote storage user via ntfy. I’m loving ntfy since there is a free hosted one and you can “hide” your messages by using hashed endpoints. I mostly use this as a dumb alert system to tell the receiving client to initiate a sync instead of relying on polling. But I digress….
I allow the user to specify a ntfy host they own, or default to using the public one (which has request limits).
In another app I manage collected video/audio for a user (https://stashcast.net/). Everything could be done client side, but there are times when a complex transcoding should be server side. This could be done as some kind of job in the cloud.
This is all to say I am leaning on services that act more like lambda functions that have no knowledge of the app. Instead of giving the users instructions to deploy to coolify, or cloudtron I am now leaning on free CloudFlare workers. (Side note: I have also starting developing a remotestorage server that can run in a CloudFlare worker).
So for a new app I may say, you need these 2 functions. Here is how you deploy them to things like:
cloudflare workers
aws lambda
gcp cloud functions
subabase edge functions
vercel functions
self hosted openfass, etc…
I am trying to think around ways to simplify this for the end user in app. This may mean some kind of generic widget where they can specify HTTP endpoints with optional headers/parameters for specific tasks.
Maybe this is out of scope for this forum, but I am wondering if anyone has thoughts around how this may work. Or am I making this too complex?
When I’ve thought about needing server resources, I tend to reflexively think about how to avoid abuse when there’s no centralized / hosted / developer-owned identity system. Honestly not sure of what approach makes sense if it’s a purely client-side app. I’m leaning towards accepting servers as a necessary evil and that, as the app developer, I host things to simplify the UX, and perhaps offer server-based capabilities as paid addons.
Have I understand correctly that you want to make it easier for people to “bring their own serverless functions”?
Ideally the it would be up to the user how they deploy these, but they could host them for themself only and require something like basic auth.
Yes.
I’m favoring functions as the server side primitive since this may be the sweet spot for less tech savy users. Perhaps copying the text of a function into CloudFlare would be simpler then figuring out how to start a web server. I’m not quite sure.
Before Paul Frazee abandoned Beaker, the thing he identified as being one of the most pernicious problems was the myriad custom dashboards that DNS registrars/hosts had, which prevented the Beaker project from being able to give simple, straightforward steps for ordinary people to follow to set up a site.
This calls for a complementary “pluggable functions provider” abstraction—not unlike the way that remoteStorage is an abstraction over different choices of providers and Sockethub is an abstraction over different content streams, it might not be a bad idea to let people (a) create an account with a supported cloud services provider, and (b) plug in their credentials to allow provisioning projects/zones/whatever other junk through a simplified dashboard that lets the user focus on the necessary parts (the credentials, what function they want to run, and what sort of budget/capacity they want to allocate to that function in order to keep it in check).
(See also: Sandstorm, which failed because of too much ambition, poor modeling of the problem, and lackluster execution—but not because there was no interest in solutions to the problems it was trying to address. And if Postman can define a new class of app (and raise $200 million) to let people manage HTTP request templates, surely there’s a place for a general “function manager” app/service that’s specifically targeted at letting people not just keep tabs on their deployments across various providers, but also manage the deployments through a unified interface that’s approachable enough for people who aren’t employed in devops.)
