Going thru the cert training, and docs in general, I see that the recommended frontend stack is to use React but I much rather use Svelte, which is where our organization has moved to, so I’m wondering how much going against the grain friction will I encounter ?
your feedback is much appreciated,
-Charles
I don’t have any experience with Svelte, but from looking at the docs I think you will be fine by using the other two provided JavaScript libraries daml/types and daml/ledger. I suggest you take a look at daml/ledger and then decide how much work it would be to use Svelte together with daml/ledger to access the ledger.
thank you , just a follow up, isn’t it possible from any UI library to interact with the daml ledger via a REST json/http API ? which it seems you provide, if so are there any disadvantages to following that route vis a vis interacting directly with the JS daml/ledger API
thanks
-Charles
You can definitely create the requests yourself as well. The advantage of using the typescript codegen & @daml/ledger is that they generate you a library that is specific to your Daml model which provides a very convenient API (and if you use typescript, a statically typed one) for interacting with your model. If you do things without that, you just have to do a bit more of the heavy lifting yourself and assemble the requests payload correctly.
thanks,
but it seems that is not necessarily just specific to the react libraries i.e. given what you are saying connecting my svelte UIs to the api generated by the typescript codegen , daml/ledger is viable.
What I still have to get my head around is that in the context of hooking up to our enterprise application it would seem that a microservice coordinating the interaction of our application with the ledger is a better approach and in that case it would be about codegen java bindings (others were deprecated) based on the specified models , therefore we would have UIs communicating with the microservice and most probably over json/https.
If that’s the approach then my question is irrelevant i.e. its really about using daml syntax to build my models , then codegen to generate API and that would be Java codegen, my microservice would expose a json/https based API to our pre-existing application for the passing of business events which would be used to update contract state on the ledger
Am I missing something ?
The microservice approach using the Java bindings is definitely also a reasonable option especially if you want to decouple your UI somewhat from your daml models.
ok, thanks