please confirm if I am right. If I want give users possibility to download pdf file by API still I should use REST API. Is there alternative?

anyone know of an example of mapping lacinia resolvers to Datomic queries? It seems like it should be relatively straightforward, but seeing how someone else has tackled it would be a big help.

Im doing it.

The code is not public. I can show bits, though.

My top-level queries return lists of entity-maps (e.g. #(d/entity db ref)), and the one field resolver are essentially (fn [context args container] (get container (datomic->graphql k)).

er, graphql->datomic

I'd love to make the code generic, but I think it's too tied to assumptions we make.

I also have utilities for converting graphql to datomic attributes and back. Also with assumptions, unfortunately.

cool, and definitely understand about not really easily-shared code.

graphql->datomic is mapping gql specification to datalog?

In this case, it's a stand in for "translate datomic keyword to graphql keyword"

Our datomic attributes are, like, ":program/legacy-degree-offering". GraphQL does not allow dashes, slashes, or namespaces, and prefers camelCase, so we mechanically map it to ":legacyDegreeOffering".

(and back)

I'm hoping to rename the Datomic attributes to be things like :Program/legacyDegreeOffering over time, but this will require a lot of little bits of work.

ah, right. that makes sense.

to some extent I’m still wrapping my head around what’s in the resolver arguments besides args, so there’s that too.

@curtosis this does a lot of the legwork https://github.com/workframers/stillsuit

ah, excellent! looking now…

What is the most straightforward way of adding extra routes using lacinia pedestal?

I can conj on the set of routes after building the service map, but I'm wondering if it is exposed on the api somewhere.

There was an example posted here a few days ago. conj is the way to go.

When you have data, less API is better.