om-next

stijn 2017-01-15T11:37:12.000291Z

@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).

stijn 2017-01-15T11:38:21.000292Z

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

stijn 2017-01-15T11:39:51.000293Z

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

stijn 2017-01-15T11:47:02.000294Z

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

sova-soars-the-sora 2017-01-15T19:43:17.000295Z

@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

sova-soars-the-sora 2017-01-15T19:43:48.000296Z

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

stijn 2017-01-15T19:51:27.000297Z

exactly

stijn 2017-01-15T19:52:46.000298Z

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?

sova-soars-the-sora 2017-01-15T20:08:05.000299Z

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