@sova: let me first start by saying we're not using om-next on the client. the clients are native android (Java) and iOS (Objective C).

the backend runs clojure with datomic, but we are looking to go away from the standard REST CRUD thing and have been experimenting with om next parser on the backend

the idea is that the client uses om next queries in the same way that it would use GraphQL without using Relay

so, one thing that comes up is authorization on the data. e.g. for an 'ordering' system in a venue, an order is placed at a bar. attribute :order/bar. with unchecked pull specs you can request :order/_bar and get orders of other clients placed at that bar. however, for an admin that might be exactly the query they need to perform. so placing a restriction on what you can express in the pull spec is not really an ideal situation I think

@stijn Hmm interesting. so somehow to restrict who can search on what terms, but you want it to be secure, so it seems like you'd need a serverside-check for "is this user/level allowed to access this information" before dishing out replies

you probably want people to be able to look at their own queries and history, but not at others', unless they're admin status...

exactly

a filtered db is probably the most secure way, but is it practically feasible to 1/ express this as a generic query like in the NuBank video 2/ performant enough?

could you point me to the nubank video? I'm wondering if you know how they solve this problem in other GraphQL