API Management Center: When to use local vs global workflows?

In the Weweb academy, @Joyce talks about building an API management center and the use of global workflows.

One part I don’t understand is, when do I use a local workflow, and when do I use a global workflow?

Right now I have:

  1. Workflows with no other similar workflows (but with API call inside)

  2. Workflows with no other similar workflows (without API call)

  3. Similar Workflows that are used multiple places but are not exactly the same (with API calls inside the workflow)

  4. Similar workflows that are used at multiple places and are exactly the same (without API calls inside the workflow)

  5. Similar workflows that call the same end point but have slightly different actions (example a default on page load workflow)

Q1: Do I build everything as a global workflow, with no local workflows, even for type 2s?
which type of workflow as seen above should be added as a global workflow and which is okay as a local one? Example maybe type 2 probably is okay with a local workflow or is it best practice to have all workflows as global workflows so we know where everything is?

Q2: When we talk about an API management center, is it a folder of workflows with only the API calls without any other actions? And then other local / global workflows will refer to that?

OR are we talking about just making sure all workflows with API calls are in a global workflow it’s sufficient?

Q3: EXAMPLE of a confusing scenario let’s say if we have type 5s (similar worjflows with API calls within), we may be calling the same API point multiple times across different workflows. Example I may have a ‘Create Post’ workflow that calls a ‘POST’ end point and this workflow also consists of other actions. But then elsewhere in the app I may need to create a post with slightly different actions but to the same end point. How do I handle this? Do I create 3 global workflows (one for the API call, one for each of the times I have to create a workflow, or something else?)

I hope this makes sense because now I have lots of global workflows and also lots of local workflows and everything just seems kinda messy :face_holding_back_tears:

2 Likes

Hi @raelyn :wave:

Great questions!

GENERAL THOUGHTS

Would love to see other developers input on this one as well because I think that, while there are best practices, there’s also a good part personal taste of the individual developer and what they feel more comfortable with. In that sense, visual programming is similar to traditional code.

To give you a general answer, I would say that workflows that fall under the 1 and 2 categories could easily stay local… until it’s time to turn them into global workflows. When is it time to turn a local workflow into a global workflow? My take: it’s time to create a global workflow when you notice you are copy/pasting things or re-doing the same thing multiple times.

Workflows that fall under the categories 3-5 should be global workflows if at all possible, even if there’s no API call inside (perhaps we should rename the video to avoid the confusion, a more helpful way to think about it could be to call it a 'user interaction management center". I’ll need to give this some thought!)

To say things differently:

  • when is it okay to create a local workflow? all the time unless you feel the need to make it global because you’re tired of re-doing the same thing multiple times.
  • when should you avoid creating a global workflow? when you’re testing an idea in a specific place and you’re not sure yet if the logic of your workflow is correct (much easier to test and debug a local workflow when you’re getting started)
  • when should you create a global workflow / avoid creating a local workflow? I don’t think you ever have to create a global workflow but there’s a general principle in programming that says “Don’t repeat yourself” so, ideally, you want to create a global workflow when you catch yourself copy/pasting or doing the same thing multiple times

ADDRESSING YOUR QUESTIONS SPECIFICALLY

Q1: you can have both global and local workflows.

Q2: the goal of an API management center is to help you maintain and debug your app. that’s why we recommend creating a global workflow when you notice you’re copy/pasting the same or similar local workflows in multiple places (because having one global workflow will ensure you only have to update or debug in one place). so you could have several folders and organize them in whatever way you (and your team) see fit.

Q3: a global workflow can include an action that executes another global workflow. in the use case you describe, you could have:

  • a global workflow called something like “update ticket record” that is just one action that makes the API call to update an item
  • another global workflow with several actions like change loader variable, execute the “update ticket record” workflow, and display success message
  • another global workflow with several actions like execute the “update ticket record” workflow, send an email, and change page

It’s not a great example but hopefully it makes sense! :sweat_smile:

KEEPING THINGS TIDY

Like you said, things can get kinda messy pretty fast. Unfortunately, that’s part and parcel of every code and no-code projects!

So much so that traditional developers invented a word, nay a verb, for it! They talk about “refactoring” your code.

The idea is that, as your app evolves and grows in complexity, you should regularly clean the code as much as possible:

  • get rid of things like variables and workflows that you’re no longer using (so it’s quicker to go through the project and understand what’s happening)
  • turn identical local workflows that are copied throughout the app into one global workflow that is executed multiple times (so when you can update or debug a feature in one place)
  • rewrite 50 lines of code that would work with 10 without losing its readability (so other people on the team still understand what it does)

Basically, project will always get messy and it’s a big part of a (visual) programmer’s job to clean it up and make it as consistent as possible so that they and their team can build, update, and maintain the project.

Sorry I know there’s a lot of grey area in my answer. Hopefully it still helps a little bit! Would love to know what others think/recommend.

1 Like