In my previous post Serverless and event-driven design thinking I used a fictitious service, serverless file-manager, as example. In the post we on...
For further actions, you may consider blocking this person and/or reporting abuse
I think this is a pretty cool series of articles, thanks for sharing. I wanted to comment on a few things, specifically around Step Functions.
It is mentioned that by using StepFunctions "we can actually delete the file without writing a single line of code", while the yaml for the state machine is around 100 lines of, more or less unreadable code. For the update flow, it's around 200 lines of yaml for the state machine.
And while I understand what is meant by "low code", these delete and update flows seem to me like some sort of business logic - remove the file, update the quotas, maybe something else in the future, etc. It is said also that this approach makes updating and debugging easier, however I am not convinced - because this business logic is now written in this state machine yaml code, instead of for example a lambda function in python that does the same thing. With that in mind, I am wondering what are the tradeoffs regarding testability of this application? Are there any "unit tests" for the state machine that can run quickly, rather then having some integration level tests running in the cloud every time?
Perhaps it wasn't in scope of the article, but I think it's an important consideration when deciding on the tech stack to use.
Cheers!
Since I always aim to keep my Lambda Function super small I would never implement neither the Update or Delete flows in one single functions. I would always use a StepFunctions state-machine to coordinate the flow. So I define
no-codein this post as no Lambda Functions and instead use the built in SDK / Service integrations in StepFunctions.From a debugging perspective. I think it's easier to debug a state-machine failure as I can fetch the exact step that failed and can inspect input / output parameters. If the entire logic was in a single Lambda function, I think the debugging would be harder. Now, not everyone thinks that and it all depends on the way you work.
From a testing perspective, you can always invoke the StepFunction with different event input an validate the output. If you like to Unit test a single step in the state-machine, no that is not possible. I however prefer testing the StepFunction logic as one entity. And I always prefer testing in the cloud with cloud resources running.
Now, everyone has their own way of working and what is easier or not. In the teams I have been working in we have preferred this way of working and felt it gave us better debugging abilities.
This is great.
Nice design, you're missing a couple of common operations in a Filesystem.
Move files-folders to another locations, rename objects.
That is absolutely true. I should have made clear that it's not a full solution, rather an embryo and a way to demonstrate serverless and event-driven systems.