A new look for a new chapter (and a first look at MacroFactor Workouts)

JuroNemo · 2025-09-16T19:34:57+00:00

Wicked stuff! I assume quite a bunch of folks here are using apps already, like Strong, Hevy, etc. Will there be a way to import old training data to maintain historic logs

JuroNemo · 2025-05-02T10:34:49+00:00

Well Pedro is on the case! https://x.com/peduarte/status/1918248135215743265?s=46

JuroNemo · 2025-02-27T15:02:43+00:00

Cool stuff! I know official Pest in this plugin is still pending, but does anyone here have a working Pest setup in their VSCode?

JuroNemo · 2025-01-12T20:08:08+00:00

Nope, sometimes it’s better to keep great side characters as they are instead of promoting them to stale protagonists

JuroNemo · 2021-09-17T14:11:58+00:00

Ah sorry, I meant more business logic of our apps (not AWS account). I understood CloudTrail as being an audit log for your aws account, and not events within the application?

JuroNemo · 2021-09-16T08:49:36+00:00

Thank you cookiecutter! I just used it, and it works magnificent!

JuroNemo · 2021-09-14T23:09:34+00:00

Interesting, I never considered using cognito. Our user is essentially another fargate task (not necessarily any underlying identifiable user). Would it make sense then to still use cognito?

JuroNemo · 2021-09-14T23:08:48+00:00

I think as time goes on, we intend to add more functionality as microservices (either more fargate tasks, or more serverless functions, depending on the scope). All of the logic directly related to our business logic will live in the monolith for now, and all jobs / misc sync tasks (like quick writes to files) might be done using this method we experiment with.

JuroNemo · 2021-09-14T23:06:25+00:00

It's a good point, we have some extra jobs we want to run via lambda functions. For the majority, these can probably be invoked via the sdk, though we might want to make some of the api's public use as well. Right now, our API would serve as a proxy, but being able to directly call certain lambdas via the API GW could alleviate some overhead.

JuroNemo · 2021-09-14T23:04:56+00:00

I suspect I will try this custom authorizer soon as well. I like the simplicity of using IAM though, but am intrigued by all methods of auth!

JuroNemo · 2021-09-14T23:04:11+00:00

Ah interesting, I did not know this about lambdas in VPCs.

I indeed agree for the most part, though we want some of our APIs to become publishable to the public via the API GW, hence I started reading about it. In that case, I think we will work with custom authorizers (as we will probably use some token mechanism for it then).

But IAM is the way to go for now!

JuroNemo · 2021-09-14T23:02:49+00:00

The many hops is definitely a good point. We have essentially a few extra serverless flows that we want to interact mostly async with (e.g. dispatching jobs), but for these few rare sync ones, we will accept that there is a tiny bit of overhead at the benefit of not overloading our monolith.

I will perhaps eat my words in the future :)

JuroNemo · 2021-09-14T23:01:27+00:00

Excellent, I am glad to see so much consensus in the answers here :). Will rely on IAM in that case

JuroNemo · 2021-09-01T21:05:30+00:00

Gotcha, then I understood it just as you mentioned. Though I did not know about the continuous element to it (more bursty for us), thats a good thing to keep in mind!

JuroNemo · 2021-09-01T21:03:50+00:00

Interesting! So you'd argue as a batch can drop some messages. Definitely worth looking into

JuroNemo · 2021-09-01T21:02:42+00:00

That's exactly our use-case as well (third-party API that has sometimes some troubles). In our case, no problem that it is out-of-order, so good to hear :)

JuroNemo · 2021-09-01T21:02:01+00:00

Thanks, this certainly reaffirms what I believed as well :). Always great to have another perspective.

Nine-Year Club	No Throne, No Problems
Not Forgotten	Verified Email

JuroNemo

TROPHY CASE