My meta side project for building other side projects: https://bodge.app/

I've always had a bunch of small side projects that I want to do that aren't worth the overhead required to actually put them together & keep them maintained. So, I built a small Lua-based FaaS platform to make each individual project less work whenever inspiration strikes. So far I've built:

* A current-time API for some hacked-together IoT devices: https://time.bodge.link/

* A script for my wife that checks her commute time and emails her before it's about to get bad.

* An email notification to myself if my Matrix server goes down.

* A 'randomly choose a thing' page. https://rand.bodge.link/choose?head&tails

* A work phone number voicemail, the script converts the webhook into an email to me.

* An email notification any time a new version is released for a few semi-public self-hosted services.

* Scrapers for a few companies' job listings that notify me whenever a new job is posted matching some filters.

* A WebPush server that I eventually want to use for custom notifications to myself.

* An SVG hit counter: https://hits.bodge.link/

Since I'm already maintaining it for myself, I figured I might as well open it up for others. It's free to play with, at least for now.

▲

adityaathalye 8 hours ago | parent | next [-]

> My meta side project for building other side projects

Looks cool, congrats on putting it out there as priced service!

And, same!

Except, it's just a repo organisation system (structure, conventions, and tools) that lets me share common "parts" across multiple "projects". No monolithic frameworks here.

Libraries are functions. Apps are objects.

However, normally, we use these as distinct artefacts, eventually leading to the "diamond dependency" problem (and lots of other annoying development-time stuff caused by libs / code that is "over there" (elsewhere)).

My "meta side project" solves, essentially the Expression Problem as it manifests in source code management (particularly, cross library / service / project feature development).

[0] https://github.com/adityaathalye/clojure-multiproject-exampl...

▲

bisaacs 6 hours ago | parent | prev | next [-]

Thanks for sharing! I signed up and tried it for something simple (storing a message via POST and displaying it in HTML via GET) and it was delightfully easy & approachable.

	▲	azdle 6 hours ago \| parent [-]
		Great to hear! And thanks for saying so. I've definitely tried to make it as simple and straight forward as possible, but I really didn't know if it would be simple and straight forward to anyone but me.

▲

catlifeonmars 8 hours ago | parent | prev | next [-]

This is great. One thing that is not immediately obvious to me is what kind of authentication it supports. Needing to authenticate the caller is the #1 piece of boilerplate that gets in the way of me completing mini-projects. It’s not hard, but it’s definitely a nonzero amount of effort. And this is coming from someone who has implemented many, many auth flows professionally.

▲

azdle 7 hours ago | parent [-]

It doesn't say because there's no special support for any auth protocols. Long-term I want to have out-of-the-box support for things like OAuth (for user-facing auth) or mutual TLS (for device/service auth). _Technically_ there's currently support for the cryptographic primitives required to do JWT (I added that because I wanted to support WebPush w/ payloads for myself), but those aren't documented because I intend to remove the current slightly-hacky custom APIs and replace them with some off the shelf libraries, but I'm still figuring out user-added libraries (and on top of that I'll also need to figure out support for native libraries).

Are there any auth protocols / flows you think would be important to support?

	▲	catlifeonmars 6 hours ago \| parent [-]
		Ah makes sense! > Are there any auth protocols / flows you think would be important to support? - I think API key passed via basic HTTP auth would get you pretty far. This is ideal for serving machine-machine requests and just requires that both parties can securely store the secret. - OIDC is great for interactions that happen in the browser or if the function is serving multiple users, but is more complicated to setup and/or use correctly. OpenID connect is probably the best for contexts where you want something served by multiple users and those users are humans. > _Technically_ there's currently support for the cryptographic primitives required to do JWT (I added that because I wanted to support WebPush w/ payloads for myself) This is probably a good intermediate solution FWIW - expose signature verification and HMAC APIs and allow a user to bring in their own implementation.

▲

mattbettinson 8 hours ago | parent | prev | next [-]

FWIW I think you should paraphrase this comment on the hero of the site! I was unclear what it did till i read your comment fully.

	▲	azdle 8 hours ago \| parent [-]
		I know the homepage needs way more answer to "WTH is it?", I just don't really enjoy doing the 'marketing' side of things. I hadn't really considered just throwing something informal up there, but I guess I don't really know _why_, so, thanks for the suggestion.

▲

saadn92 7 hours ago | parent | prev [-]

Love this, especially the commute idea

	▲	azdle 7 hours ago \| parent [-]
		Thanks!