Product Refactor & DFC / REST API discussion [Jul 2023]

Product Development
,
1

Continuing the discussion from Product Model Refactor and varying discussions around DFC / REST API etc.

We currently have a situation where we have a lot going on in relation to Products. We had a little huddle in Aus yesterday to get heads around or at least communicate across a few of these e.g.

  • Product refactor is underway (led by @Matt-Yorkley) - this is currently focused on moving variables out of the Product model into Variants model
  • Once we have done this we need to introduce a Product ‘Group’ so that we can connect Variants.
  • These changes will impact on the REST API - bulk-products. This is v0 and not supported, but used in quite a lot of integrations, so we do need to reflect refactoring changes in api and highlight them in release notes

We are also building a new Product interface and mobile version (BackOffice Uplift), and there are some architectural considerations in this re. use of API/APIs, so this broader context is also relevant to @dcook and @jibees (and @Mario to a lesser extent)

In parallel work has progressed on DFC Products Connector which is now quite functional at our end, but a little unreliable / unsupported from DFC end. In Australia we are considering whether we should migrate our existing integrations that use the REST v0 Product endpoint to use DFC Products. To this end we have:

  • set up experimental N8N GET DFC Products → Airtable integration (excellent work by @div-yansh-1)
  • mapped all the fields used in our product integrations (so that we can more easily manage and fix breaking changes) (currently in Notion as that’s where we work but can move to google sheet if useful to others globally)
  • cross-checked this against DFC Products Connector - everything is there except the Product ID and Name (which is handled separately still in OFN). Should we just create these fields on the variant as our ‘Product Group’ fields?
  • identified a naming issue i.e. that DFC is currently passing Variant name (display_name) and not Product name. This behaviour doesn’t work correctly with OFN current logic. @maikel is going to fix this in the DFC Connector - GH#11229

We are in active discussion about this. If Australia / OFN wanted to move ahead in adoption of DFC Connector, what do we need to think about:

  • What are the risks to our integrations? Does the DFC Connector break (in our usage) if DFC changes ontology or does it still work but is then out of step with prototype etc?
  • If we actively adopt DFC Connectors we are likely to want to add things to them. What happens if these aren’t yet in ontology? Can we fork / PR? Suggest into Ontology?
1 Like
2

Just updating from follow-up chat with @maikel . It is clear that we need to pause and not progress any migration at the moment because:

  • we can’t actually access DFC (broken)
  • we are waiting on fixes and also responses to questions / suggestions about how processes can be made more robust / scalable (hopefully in next couple of weeks)
  • there are a few things we need to do (as above) to get the Connector to have all the data we need

Hopeful that progress on these will happen over next couple of weeks then we can revisit :slight_smile:

3

For existing integrations: I’m left wondering what the benefit of using DFC would be?
The OFN model doesn’t map perfectly to the DFC model, and neither will the integrations, so it seems like uneccessary extra work.
It’s a great long-term goal, to get OFN and our integrations speaking the same language, which is an international standard.

But if DFC continues to change, then it’s only going to add more work. The DFC version supported by OFN (currently 1.7) will change, and when OFN upgrades, the integrations may need to be updated too.

So from my point of view, it seems it would be less work to just adapt to minor v0 api changes as they come.