Hey community, just reading up about blocks in 2.0. Really interesting construct. I like the idea of the use for secrets and accessing aws, database etc etc. Currently we use 1.0 and have an internal "task library" type of dealio. Are you guys recommending that blocks could be used for something like that, so that you avoid duplicating general tasks across several repositories or is it best to keep tasks with logic away from blocks? It's appealing from a visibility standpoint in the UI but perhaps dangerous from a testing standpoint if someone accidentally changes something in a block that other repos rely on. Keen to hear your recommendations!

Great question and definitely something that would be doable. We typically recommend a pattern where you would use blocks for secure stateful configuration to external systems, including passwords, etc., and use a Prefect Collection (can be both public or private) to store a collection of related tasks. However, nothing stops you from adding extra methods to your custom blocks, this should be possible too, but the most common and easiest to manage pattern is to use a combination of Blocks for stateful secure configuration and collections for business logic/code. I'll cc @alex since he's the best person to answer this.

Thanks @Anna Geller

I agree that using blocks for storage of configuration and passing a block as an input to a task is the recommended pattern. This is primarily because methods on blocks currently cannot be executed as tasks, and any functionality that interacts with an external system via a network call should be executed as a task for reliability. However, any functionality that is shared between different tasks that use block can be encapsulated in block methods to avoid repetition. This is useful for stuff like initializing clients for third-party systems that you’re interacting with. That’s a pattern that you’ll see repeated frequently across the collections that Prefect maintains.

Thanks @alex, is there rbac control over blocks too? That seems like it'd go hand in hand with the pattern

not yet but definitely something we'd love to explore in the future -- I'll make a note to myself that you'd be interested in Block-based RBAC - thanks for raising that