Exeter Meeting Notes

June 24-28 Present HO, DM, MS, OS, SB, BK, TP

UI Session

Job to UIS/WFS authentication/trust:

Cylc Workshop 2019/2020


Protobuf discussion (as implemented by DS already):

Future, Cylc 9:


Cylc-8 release schedule?

DS Notes:

I’ve already discussed some of the questions/features, but just thought I would responed to other points relevant to me:

  • GraphQL has typing too (like Protobuf); not sure if validation/checking is done
  • BK wants types in the UI for safety/robustness

As discussed with Bruno, GraphQL does request/query validation (both field and Arg/Var type checking) and type validation on data returned by the resolvers.. This covers all bases, and means you don’t have to follow any bread crumbs in finding errors.. The fact that both protobuf and graphql definitions are in cylc-flow makes it quite robust (both WRT development and production).


  • note graphene (Python client/server) is much less powerful than >Apollo (JS)

We’re not using python client, but would agree Graphene is probably not as “powerful” as Apollo GraphQL Server.. There’s technology out there to write language agnostic GraphQL schema, so cylc-flow could possibly still share it’s schema with a non-python implementation, and with use of a Redis like data store perhaps we could migrate the UIS/Tornado to something like Apollo GraphQL Server… However:

So not sure this is worth entertaining unless we are suffering in performance after optimisation (or there is other interplay from having Apollo client & server)..

  • request for “hold all of my suites”: “workflows/*, status=held”

Already capable… Use the GraphiQL interface docs to find out (or just ask!)

  • (what about: hold all tasks submitting to host X?)

Would need to add an arg for host, and possibly a field to taskProxy (and that could be cross/multi-workflow also)

Protobuf discussion (as implemented by DS already):

 decision: Protobuf is fine for the current model where UIS is >mirroring all
 data in the "active view" of WFS. GraphQL backend potentially >better if in
 future we can make the UIS merely a transparent conduit for exactly >what
 subset of the data that the UI requests.

I think I may have spoken to this point. We don’t want to place strain on the WS by the GUI (something BOM also stressed) and it becomes highly inefficient/impractical for multi-workflow queries… If you still want GraphQL at the UIS (it not just be a proxy to the WS), in order to unify the CLI we import the schema from cylc-flow so you can’t have both..

  • still need protobuf feed somewhat granularized to level of nodes >and edges,
  • so UIS doesn’t store edges if no one is looking at the graph view.
  • Ask DS not to granularize further than this, if not strictly needed.

Not sure there’s a massive benefit from doing this… I think we could definitely only sync when a user is connected.. In the spawn-on-demand era we may have to generate edges and nodes on the fly from the workflow pattern (else looking into the future might be hampered), but we still have to store “what happened” somewhere..


  • WFS populate in memory DB (redis etc.) … then UIS can just query >the DB?

Could be beneficial if directly exposed (like redis), then no need for data store sync with WS => UIS (as they would both use this).