Auth0’s Actions gives developers customizable, extensible capabilities, as well as low and no-code options.
Read more…
Brought to you by Dan McCorriston
Auth0’s Actions gives developers customizable, extensible capabilities, as well as low and no-code options.
Read more…
Brought to you by Dan McCorriston
What are your thoughts folks? Share it in the comments!
I’ll share my thoughts… I do like the Actions themselves as it’s a single unifying place for things I used to have in Hooks/Rules.
However I notice that there’s a huge focus on keeping the devs within the web interface - writing the code, using the browser based editor, committing, and deploying, all from the Auth0 Dashboard. In other words, everything is ‘point-and-click’ first and automation feels like an afterthought. Especially this line,
Serverless extensibility so your code is hosted and maintained by Auth0.
I may be in the minority here, but I am very uncomfortable with this. I like to keep my code near the rest of my code, so I don’t see the advantage here. I’d like my code to be able to go through build pipelines, especially code related to security, but this is the antithesis of that.
There is a lack of focus on testability, and automation especially around deployments. During the initial rollout of Actions, the Auth0 Deploy CLI lagged far behind and the Auth0 Deploy CLI finally got the Actions features much later.
Testability is pretty important for me but I’ve not seen any useful guidance around that, so from a code quality perspective, it isn’t better than hooks and rules. (I’ve basically hacked the unit testing myself by relying on the methods being exportable.) There is no way to specify configuration values other than putting configuration values in to secrets.
Minor note - it’s “tl;dr” not “tr;dl”
Thanks for sharing your thoughts!
Hi there
after trying to migrate all our rules and hooks to actions I have to say it is not quite production ready.
The main issue is this limitation:
Top-level
event.user
attributes added by an external IdP or custom database script
As long as this is not available we still need rules to get around this limitation. I hope this gets resolved before you remove rules altogether.
Then there is the issue with the Library view. You have to wait several seconds until it is finished loading whatever (actions marketplace data maybe?) before you can switch to the “Custom” tab to get to your code. It would be great if the view could persist the selected tab (Installed or Custom) when comming back or show the same behaviour as the Extensiosn view where you can instantly select the “Installed” tab.
I love the feedback on the limitation. Account linking is something we’d love to shore up in our parity gaps. We’ll be working on this in the coming months. My goal is to bridge the remaining parity gaps in Actions this year.
As always, thank you for your feedback,
Darin, Head of Ecosystem Product.
@sha256 - Thanks for the feedback! I agree, we were a bit lagging on the Deploy CLI, it was a missing piece when we launched Actions in Beta and we didn’t deliver until the GA.
We’re currently working on adding non-secret configuration into Actions, I hope this will help.
-Darin, Ecosystem Head of Product