You could also just use ions with HTTP Direct.

(I’m assuming you’re wiring these up to an API Gateway.)

They stay spun up.

You have to handle routing within the ion, but it has a significant (positive) response time impact.

sounds promising but i don't quite follow. HTTP direct lets me route api gateway traffic directly to datomic, but i don't see how that lets me query datomic from a cljs (nodejs) lambda which is my goal 🙂

it looks like on-prem has a REST api, maybe cloud has something similar?

What’s your Lambda hooked up to?

Typically, I only worry about cold starts if it’s user-facing.

(Though I suppose there’s a Rube Goldberg version that hits a private API Gateway endpoint proxying directly to an ion.)

^ yeah, i entertained the idea 😉 i don't have a specific use case, but let's say something like an API Gateway Authorizer, or an authentication lambda hooked in to Cognito, both of which are customer facing

Not too long ago I went and made a nodejs cloud/peer server project: https://github.com/csm/datomic-client-js not official, but it does work with cloud and peer server

Neat.

Alas, not a lot of good options there if the Lambda is low traffic.

Even the Lambdas created to proxy to ions use the JVM if I’m not mistaken.

The API Gateway version might be the best option, latency-wise 😛

@UFQT3VCF8 this is fantastic, thank you for sharing! i'm curious - why did you write the library in JS and not CLJS?

The peer api is the api used to become a peer. A peer server is a peer that provides the server half of the client api

“peer” means roughly “member of the datomic cluster”. They have direct connections to transactor and storage

https://docs.datomic.com/on-prem/architecture.html#peers

@U09R86PA4 thanks, I think it makes sense now. Peer and peer server is the full Datomic api with caching etc, where Client is just an interface that connects to the peer server.

correct. Although a bit of nuance: the client api is designed to be possible to use from a non-peer process, but in certain circumstances for performance it can actually run in a peer and use that peer’s resources directly

I think this is what ions do

they use the client api, but ion processes are also peers so the client api is implemented to call directly into the peer api without crossing a process boundary

Interesting, but this is some custom thing that is happening? I was curious if you could use the connection from the peer api with a client, but the apis didn’t seem compatible, with Client requiring an endpoint. But there was a :server-type :local which I couldn’t find docs on that made me wonder

there are three implementations I know about: client (use a transit connection to a server, shared by peer-server and cloud, used by ion if running outside the cloud), peer-client, and local (used by ion if the ion is running in the cloud)

peer-client looks like it would be for on-prem peers; local is for cloud “peers”

but I’ve never seen the implementations for either one, and I don’t think they’re directly supported