Do I understand well, that the current recommendation is to always use the randomly assigned ClientApiGatewayEndpoint
as the value of the :endpoint
, even when the code is running on the compute nodes?
Former ion-starter example was using a stable, internal URL as the :endpoint
value: http://entry.mbrainz-stu.us-east-1.datomic.net:8182
, which was only resolvable within the Datomic VPC.
As I see, that is still available and still works.
Does AWS do any network access optimization, when accessing the ClientApiGatewayEndpoint
, as opposed to the DispatchAddress
?
The Datomic Architecture | Datomic diagram suggests that the ion application should use the fixed, internal DNS name for the ALB.
The latest documentation at Ions Reference | Datomic shows a public address as the :endpoint
value:
(require '[datomic.client.api :as d])
(def cfg {:server-type :ion
:region "us-east-1"
:system "inventory-dev"
:endpoint "https://ljfrt3pr18.execute-api.us-east-1.amazonaws.com"})
(def client (d/client cfg))
The ion-starter project has a similar config:
{:server-type :ion
:region "us-east-1"
:system "mbrainz-stu"
;ClientApiGatewayEndpoint output from cloudformation stack
:endpoint "https://a2id5latdd.execute-api.us-east-1.amazonaws.com/"}
These 2 examples suggests that we are supposed to use this randomly created ClientApiGatewayEndpoint
, when we want to connect to our Datomic Cloud System (DCS further on), regardless of accessing it from the Datomic EC2 instances or through the internet.
This however, assumes that we provision our DCS first, then we either include this randomly named endpoint into the artifact, we `clojure -M:ion-dev ‘{:op :deploy}’, or push it somewhere as a configuration for the ion app to pick up during its bootup time.
If that’s the recommended approach, I would like to have some guidance on how to determine the :endpoint
address, if it depends on the development stage?