Maybe you've read my multi-part series (part 1, part 2) about building my first Kestra flow? Maybe you noticed I made it overly complicated. But here is where you benefit! I have tons of tips and tricks for you.
Just like any list of tips and tricks, some will be a technical requirements while others will be a preference. If you prefer something different, that's totally fine and I'd love to hear about it in the comments.
Let's dig in!
Name your flow id something relevant
Out-of-the-box, you are going to get something auto generated as your flow id that has no relation or relevance to your flow. Change it before you save your flow or you'll need to make a new flow.
Do you know what lyrebird_805364 is? Neither do I, so I have to click into it to refresh my memory. It's my small example flow for debugging Confluence version info and passing an expression as a number. Obviously.
The id must be unique and, like mentioned above, it's immutable, so if you forget, you'll need to create a new flow with the id you actually want.
Keep your YAML readable
One of the biggest benefits of YAML is the human-readable nature, but you can quickly make your YAML really messy, whether it's YAML for a Kestra workflow or something else.
Remember you can add comments and spaces to keep your YAML readable. I like to think about it almost like a blog, I want to be able to read it top to bottom with some amount of structure, and that includes blocks separated by spaces.
Triggers at the top
Most ordering of information in your flow code doesn't really matter, but when you take into account the human-readable aspects of YAML, I like having my triggers at the top of my file just like I read top to bottom, down the page. Without having to look anywhere else, I can see exactly what triggers the rest of the flow.
Similarly, I put outputs on the bottom, but admittedly, I've only done trivial things with outputs, which is why I didn't call this out as a separate tip. Where would you put your flow outputs? Top? Bottom? Depends?
Chunk it up during development
If you know you are going to build a large or complex flow, as you piece it together, consider building in chunks in separate flows or using comments.
As my "first flow" got bigger and bigger, I wanted to focus on the part that was new or the plugin that wasn't quite working yet. Sometimes I would pull chunks up to the top of the flow so they ran first, or comment out sections I knew were working, or even create a new, small flow with a single plugin to remove any other variables that might be making something not work as expected.
My favorite keyboard shortcut is commenting/uncommenting large blocks with option + / (on Mac at least). Hit the ... menu in your flow code editor and find the rest of the keyboard shortcuts.
Secrets need to stay secret
I am one of those notoriously lazy developers who just slaps credentials in plain text, particularly if I'm developing PoCs locally. Who is going to see it? My cat?
Revisions are created with every save, so if this PoC does evolve into something bigger, your credentials are certainly in a revision, maybe even several. You could go through and delete revisions, but using environment variables or the EE Secrets will save you a lot of annoyances.
Don't be like me and hide your secrets from the start.
Try the No-code experience
Even if you are a hardcore developer, the no-code experience is pretty neat. If nothing else, it's cool to see what you could add to your flow and the changes propagate in both directions, so you can shift back and forth between flow code and no-code.
The no-code editor also shows me the type for each property which I find a little bit easier to parse than the documentation window at times.
If I had a bigger monitor I might consider keeping the flow code, no-code and documentation windows all open at once.
Plugins are evolving
Some of the plugins are incredibly new and specific to a single use case or flow. If they use 3rd party APIs, they may not include all endpoints or all APIs for a given technology. Between the very engaged group of contributors and passionate Kestra employees, if you see something that doesn't work or doesn't work the way you want it to, simply create an issue for a bug or feature request. It will get triaged and addressed. But what we don't know, we can't fix!
Similarly, if you see an integration is missing, you can create a plugin yourself. The flexibility here is great.
EE users can also update plugins directly in the UI, which I did several times as new updates extended functionality or fixed bugs.
Did I miss a tip or trick that's your favorite? Let me know in the comments. And as always, I'd love to know what you are building with Kestra so give me a shout!
Top comments (0)