Current Supported Flows

flows

#1

Current Supported Flows

  • Products
  • Orders
  • Customers

Each of these Flow types supports the following field types:

  • String
  • Integer
  • Float
  • Boolean
  • Date

There are no default fields or entries on these flows, you will need to specify your field
names and types when you create them.

For more information on Flows please read our blog post explaining how to get the most out of
your custom Flow data.


#2

I was a bit disappointed with that blog post… it ended up being a bit like clickbait in that it had lots of info but somehow failed to answer fundamental questions. Let me share a bit of my own experience after scratching my head and struggling with this.

Clarifications

  1. “Flows” in practice allow you to implement groups of custom fields.
  2. The “slug” you use when defining your flow matters. Specifically, you can augment the built-in core schemas by using a slug value of products, orders, or customers. Once you change the slug of your flow to one of those things, requests for a resource will include the new custom fields in the response. Yay! (The blog post’s explanation of this was murky).
  3. Moltin is “headless”, but really it is only “half-headless” since there is a dashboard where you log in. In the dashboard, you can create your flows, products, et al, but when you augment a core schema (e.g. by adding custom fields to your products), the dashboard will not magically unlock a way for you to add values to those fields in the GUI. (I’m not sure if this is supposed to be the case or not… the feature seems half-baked if there is no GUI counterpart).

Recommendations to Moltin:

  1. Include a feedback link on all blog-posts and API docs so that the community can help fill in any gaps in explanations.
  2. Rethink the name. “Flows” means either nothing or many things… at best it sounds like a DevOps term for CI/CD. Consider “custom fields” or “schema extensions” or something more descriptive. The API docs describe them as “data overlays”, and that’s more descriptive, but it would be far better if the resource itself had that name. Paraphrasing the wisdom of Robert C. Martin and his book on Clean Code, if you are relying on a comment to describe the purpose of a thing, then you should rename that thing.
  3. Remove the phrase “of course” from that blog post. I would go as far as to add it (and a few other choice phrases) into a pre-publication check. If your tutorial or man-page contains that phrase (or others like it), then stop the presses and make corrections. See https://medium.com/@craftsmancoding/wtfm-dbbec02eb172 for more thoughts on the matter.
  4. Edit the above comment so it references the lowercase schema slug (e.g. “products”) and not “Products”, otherwise we are left to assume that the 2 are equivalent and at best that’s imprecise.
  5. Ensure that the GUI allows users to add values to the fields that the flows define.
  6. There needs to be an example of how to use the API to add values (entries) to these fields… how do we ensure that our new augmented customer/product/order is updated with our new entry values? Are 2 API calls required (one to update the built-in resource and another to create/update the entry?). Since the GUI doesn’t support this editing, it’s imperative that the API is clear and working. So far, I have not been able to update any records with the new values, although somewhere I’m able to create entries following the API docs, but there’s really not much context to how that should all fit together.

Thanks for your consideration. My 2 bits.


#3

Thanks for the detailed feedback, we’ve also received your additional thoughts you kindly provided to Meg over email.

agree

We appreciate your understanding and agree with your points regarding flow feature functionality within the API, dashboard and that the documentation could be much better. I can’t give ETAs right now on when we’ll have these improved but we’re working super hard to ensure the moltin solution is super easy to pick up and use (both from an API and dashboard perspective).