Fork me on GitHub
#portkey
<
2017-09-22
>
qqq17:09:01

In my understanding, aws lambda functions are STATELESS. In the counter example, where is the counter atom stored ?

qqq17:09:13

Does it auto setup dynamodb/auroradb in the background or something to store the data ?

cgrand18:09:57

I have plan to use metadata on atom to use e.g. DynamoDb

cgrand18:09:02

Tracked is a strong word in this case.

cgrand18:09:44

But the idea is to deserialize the atom as a special implementation instead of a regular atom.

viesti17:09:39

So this was a bit of a hack :) The Lambda runtime keeps the process running the handler alive for some period, just like FastCGI back in the old days. In the demo, we used this aspect to store request count in a Clojure atom.

viesti17:09:31

Normally one would store state in a database. But since the runtime keeps the process running the handler alive, one can do initialization, like say creating a database connection, that would otherwise cost too much to do on every invocation.

viesti17:09:29

I think this process liveliness aspect makes things like http keep alive or sql database client side connection pools possible

viesti17:09:39

So yes, Lambda is best though of as stateless, but a process fork for each event still would cost too much even nowadays :)

viesti18:09:12

So in the demo, the process running the lambda handler kept the counter atom in memory. Iā€™m pretty sure that there were multiple processes running, which resulted in multiple separate atoms, which you could call a demo effect šŸ™‚

viesti18:09:16

last week Tatu used portkey in a livecoding event, but then with a RDS PostgreSQL, so the observed state was a bit more consistent šŸ™‚

cgrand18:09:57

I have plan to use metadata on atom to use e.g. DynamoDb

cgrand18:09:13

@qqq how would you like to use portkey?