IronFunctions VS docker-flask-example

> Also everything was new at one time.

Hah, this is a good point, but in my eyes lots of things that were new... never really grew up and were just deprecated and died.

For example, if someone based their setup on IronFunctions, they might have run into a bit of a painful situation, seeing as the project has been largely abandoned: https://github.com/iron-io/functions

Same for a database solution like Clusterpoint, the support for which just ended and you were left to migrate away to something else: https://github.com/clusterpoint

Ergo, I'd say that it's good for others to suffer the consequences of being trend setters and making wild bets on new and risky products and to just reap the benefits of their efforts later yourself, when things are safer. If a project has survived for a reasonably long time, it's a good indicator that it'll probably keep surviving in the future as well (there was a name for this, sadly can't recall what that was).

> I’m of the opinion that lambda-as-in-serverless is an evil.

Are there any other serverless solutions that you'd recommend?

Maybe a more open cloud function solution that could also be self-hosted, should the need arise?

As far as I know, OpenFaaS might serve that niche for some, though of course there will be no cloud solutions as large as Lambda available: https://github.com/openfaas/faas

Also there used to be IronFunctions, but those seem basically abandoned at this point: https://github.com/iron-io/functions

The ledger Tron proxy is not working so you will have your money but the ledger live can't see it. I'm not sure if anyone has logged a ticket, but I do believe if you go into developer options in ledger live you can make it connect directly to iron.io and that will resolve it. Only works on desktop though. I'm also getting some other errors randomly so perhaps there are some bigger issues. Anyway, I'd suggest the dev option to check it out.

I've been maintaining my Build a SAAS App with Flask video course[0] for 8 years. It has gone from pre-1.0 to 2.3 and has been recorded twice with tons of incremental updates added over the years to keep things current.

In my opinion tutorial creators should pin their versions so that anyone taking the course or going through the tutorial will have a working version that matches the video or written material.

I'm all for keeping things up to date and do update things every few months but rolling updates don't tend to work well for tutorials because sometimes a minor version requires a code change or covering new concepts. As a tutorial consumer it's frustrating when the content doesn't match the source code unless it's nothing but a version bump.

I've held off upgrading Flask to 3.0 and Python 3.12 due to these open issues with 3rd party dependencies https://github.com/nickjj/docker-flask-example/issues/17.

[0]: https://buildasaasappwithflask.com/

I usually end up with project specific "run" scripts which are just shell scripts so I can do things like `./run shell` to drop into the shell of a container, or `./run rails db:migrate` to run a command in a container.

Here's a few project specific examples. They all have similar run scripts:

    - https://github.com/nickjj/docker-flask-example

There's a lot of "tool" selections in that repo.

If anyone is looking for ready to go web app examples aimed at both development and production, I maintain:

    - https://github.com/nickjj/docker-flask-example

Personally I maintain https://github.com/nickjj/docker-flask-example. There's also https://github.com/nickjj/build-a-saas-app-with-flask if you want more opinions.

This is what I do except I use a shell script instead of a Makefile.

A working example of this is at: https://github.com/nickjj/docker-flask-example/blob/912388f3...

Those ./run ci:XXX commands are in: https://github.com/nickjj/docker-flask-example/blob/912388f3...

I like it because if CI ever happens to be down I can still run that shell script locally.

> I've encountered a code written in the 12factor style of using environment variables for configuration, and in that particular case there was no validation nor documentation of the configuration options. Is this typical?

I don't know about typical, it comes down to how your team values the code they write.

You can have a .env.example file commit to version control which explains every option in as much or as little detail as you'd like. For my own personal projects, I tend to document this file like this https://github.com/nickjj/docker-flask-example/blob/main/.en....

I did this for a while but make isn't well suited for this use case. What I end up doing is have a shell script with a bunch of functions in it. Functions automatically becomes a callable a command (with a way to make private functions if you want) with pretty much no boiler plate.

The benefit of this is it's just shell scripting so you can use shell features like $@ to pass args to another command or easily source and deal with env vars.

I've written about this process at https://nickjanetakis.com/blog/replacing-make-with-a-shell-s... and an example file is here https://github.com/nickjj/docker-flask-example/blob/main/run.

There's: https://github.com/nickjj/docker-flask-example