Anyone know where I can find examples of ions with a ring/pedestal handler?

How do we justify Datomic vs Amazon QLDB. Some features look similar. Any ideas?

Maybe you can elaborate on how they look similar? I don't see the similarities so much

@jeroenvandijk immutable, history, sure datomic supports rich querying capabilities,

I hope this doesn’t come across as overly cynical; I haven’t had my coffee yet this morning. That said, if someone is asking you to “justify” Datomic over QLDB as a choice for your system of record, my immediate tack would be to investigate why I was stuck trying to get all my architecture decisions past someone whose default position is “but AWS service exists and it’s close, use that.”

The second thing I would say, though, is “QLDB is clearly, both in terms of released features and in terms of AWS’ own documentation about it, meant to be the backing store for an immutable ledger, e.g., a managed, centralized deployment of “blockchain!“. We aren’t building “blockchain!” with this effort, are we? Please tell me because if we are I need to go short my RSUs.”

qldb appears to be indexed

not the same a blockchain

Also: All of your decisions should be justifiable compared to other options.

There’s nothing wrong with someone asking questions. Those are usually helpful when trying to think through your options.

My first answer would be they are two different things and you should try both to see the difference, if you don't see the difference already. I would for instance have to try QLDB to fully understand it's implications

@potetm I was being snarky and reading perhaps too much into the original question’s formulation of “How do I justify Datomic vs. QLDB” - which seems to me to describe less an honest question and more a “nobody ever got fired for buying AWS” reaction

And my dim view of all things ledger-y is of course also just snark and deep suspicion of hype. There are plenty of great applications for ledgers and I’m sure that if the OP is building one of those, QLDB is in the running for a backing technology of choice. My initial take was that either they aren’t and someone is asking them, essentially, “but you said Datomic is great because it’s immutable; well this new QLDB thing is immutable too, so why can’t we use that instead?” or that they are building a ledger and then my question is “do you know why you need a ledger for this application or are you on the ’chain train?” 😇

I don’t think being indexed disqualifies QLDB as not being a blockchain technology necessarily (see nanocurrency). From the surface, it seems like one of the main practical differences between using Datomic or QLDB is the ability to cryptographically verify your ledger history out of the box. If the application needs this sort of functionality it might be worthwhile to forego the read/write expressiveness etc that Datomic offers and use something more tailor fit for that use case.

That said, this could probably be implemented on top of Datomic, but that’s additional development effort.

Datomic’s datom limit may also be something to consider when choosing Datomic

@rnandan273

@petr https://github.com/pedestal/pedestal-ions-sample , https://github.com/pedestal/pedestal.ions

@cjsauer What Datom limit are you referring to? Can you add a reference to where you read this?

@joe.lane I’ve heard that larger databases can become problematic, but according to this post it isn’t a “hard” limit: https://forum.datomic.com/t/datomic-cloud-datom-limits/473

HCA gave a talk at this year’s Conj that showed how they were hot swapping Datomic databases after they had “filled up”. But as @marshall says in that post, it may be a “data shape/usage” constraint.

Found the talk: https://youtu.be/AyWbB52SzAg

Hmm, I must have missed that part of the conj. I’ve run multi-tenant datomic cloud databases in production and its pretty seamless.

Thanks for the reference, was the talk referring to on-prem or cloud?

I think it was on-prem, and a lot of the things they were encountering are unlikely to be issues w/cloud

Yeah I believe it was on-prem as well, but don’t quote me.

> a lot of the things they were encountering are unlikely to be issues w/cloud This is good to know. Do you have a specific example @alexmiller? I ask so that I don’t propagate any misinformation regarding the latest and greatest.

well with db size, a single cloud system can support many dbs, so the size thing has more ways to mitigate

and I think they were talking about restart time or something, which is a non-issue

sorry, I didn’t catch the whole talk

That makes sense. Hot swapping to a new db might just be a config change in Cloud.

I don’t think you even need to do that - one cloud instance can host many dbs so don’t think you need to change any config at all, just prob an app issue.

Talking with @marshall at the Conj, I recall him mentioning a potential issue using the new aws api with Datomic cloud until the next version of Datomic is released, though I think it was limited in scope. I don’t remember the details, however. Can anyone fill in the gaps in my memory?

That’s Correct. The currently available release of Cloud uses an older version of an http client that will not work with aws-api

Thus you can’t run the aws-api in ions right now

Thanks, @marshall for confirming. Any word from AWS on when the next version might drop?

i don’t have an update there

as soon as possible

@solussd I saw your thread about no such var errors in datomic client api from few weeks ago

Did you ever find a resolution there? I’m having a very similar issue with a basic datomic connection

@jonathan617 what's your issue?

For dependencies I have

[[org.clojure/clojure "1.8.0"]
                 [com.datomic/client-pro "0.8.28"]
                 [com.datomic/client-impl-shared "0.8.28"]]

And then I require like

(ns datomic-client-example.core
  (:require  [datomic.client.api :as client-api]))

And then do this,

(def cfg {:server-type :peer-server
          :access-key "..."
          :secret "..."
          :endpoint "localhost:9001"})
(client-api/client cfg)

the first time the error was CompilerException java.lang.RuntimeException: No such var: p/recent-db, compiling:(datomic/client/api/async.clj:101:9)

Take out the dep on client-impl-shared

but now it’s CompilerException java.lang.Exception: namespace 'datomic.client.api.async' not found, compiling:(datomic/client/api/sync.clj:16:1) every time

@jonathan617 Take out the dep on client-impl-shared

And restart your repl

@marshall thanks, I did that, and now it does this

datomic-client-example.core=> (client-api/client cfg)
2018-12-03 15:57:14.299:INFO::nREPL-worker-0: Logging initialized @11630ms

CompilerException java.lang.RuntimeException: Unable to resolve symbol: int? in this context, compiling:(datomic/client/impl/shared.clj:349:13)
datomic-client-example.core=> (client-api/client cfg)

CompilerException java.lang.Exception: namespace 'datomic.client.impl.shared' not found, compiling:(datomic/client/api/sync.clj:16:1)
datomic-client-example.core=>

That client version may require clojure 1.9 not sure

oh geez let me try that

yep that was it

thanks 🙂

https://github.com/pedestal/pedestal.ions

Q: do component entities maintain a sort order? I suspect so and I want to rely on it but I can’t find any docs on this

@dustingetz (and anyone who cares) I just used that library in combination with https://github.com/walmartlabs/lacinia-pedestal to serve graphql from api-gateway using pedestal for interceptors and web related stuff and then lacinia-pedestal for my resolvers and gql stuff. Datomic cloud for the database the resolvers work upon. Works against apigw with curl but graphiql doesn’t work because apigw hasn’t released their new websocket support yet. Soon I’m sure. That being said, because I’m using pedestal I can run graphiql locally and have this whole stack running on my laptop (except for datomic cloud of course, may be able to mock it but haven’t invested in that yet.)

@joe.lane that’s good to know. I’m using AppSync with Ions but I suspect lacinia-pedestal might have less overall complexity. I’m curious why graphiql needs websocket support? I’m using it in my re-frame client and I don’t see any websocket requests

do you mean for subscriptions?

The lower complexity is exactly why I wanted to do this.

I’ll confirm the behavior

Can I ask what re-frame client you’re using?

I’ve been eyeing re-graph

I’m currently using artemis but I’m gonna spike re-graph and sub-graph as a replacement - again to reduce complexity. artemis does not appear to be originally designed for re-frame

and using shadow-cljs to add graphiql via npm

Once apigateway releases websocket support (🤞 soon) I’ll probably write my own subscription streamer and have a serverless graphql stack.

I think my problem is that I’m not serving the assets from the right place, thanks for the feedback. I saw websocket errors and assumed thats why it wasn’t working. Just confirmed I get those locally as well so I may be able to still get it to work!

agreed, it should work. it could be the first request which is an OPTIONS instead of a GET that is breaking via apigw

I think that request reads the meta-data for your GQL schema

I’d really like to know if you can make that work. it’ll be one more data-point to convince me to switch over

I’m gonna hack on this, will let you know tomorrow or later tonight.

I think its possible, i’m just not correctly exposing the assets directory

great thanks. btw if you need subscriptions sooner, you could always use AppSync just for the subs and accept the extra complexity in a constrained area

although I haven’t tried appsync subscriptions with Ions so not sure if it works

graphiql is being included from lacinia-pedestal on my behalf. Its configured on rn but I can turn it off in prod mode.

appsync + ions works, the subscriptions only work if you mutate through appsync though. Thats why I want this to be backed by lacinia, my ions can then send outbound updates if changes occur outside the purview of appsync’s graphql api.