Query Re Method for Integrating with Non-supported API

I am planning a Daml-app that will simulate the most simplest of lending use cases, a fixed term, fixed rate loan, details as follows:

  • Amount: $5000
  • Term: 60 months
  • Rate: 17% per annum
  • Rate type: Compound
  • Setup fee: $250
  • Lender: (Me, my bank account)
  • Lendee: (Me, another bank account)
  • UI: Default

So nothing major, however I am planning to integrate it into the Payments NZ API Centre system which I now have access to, and AFAIK, this is an unsupported API.

Reading through Project DABL over the weekend, it seemed like this might be the best way to go as DABL is purpose-built for APIs on the web. The commensurate API code from Payments NZ is straightforward.

Would it be better to make a DAML project, then code in the external API(s) or write an application that uses the APIs, then try to connect that to a Daml Ledger?

Sorry, if the question is a bit vague :grinning:

2 Likes

I’d probably recommend a third option: Interleave both parts and develop them in lockstep.
Your Daml model will probably need some changes to make it easy to integrate with an external service and the other way around, how you integrate with the service depends on how you structure your Daml model.

This isn’t all that different from what I would recommend for developing UIs. If you try to develop your UI independently from your Daml model you’ll often end up having a hard time connecting the two.

4 Likes