Clojurians Log v2

Two very interesting projects i just became aware of http://book.fulcrologic.com/#_data_driven > The basic idea is this: Your UI, which might have various versions (mobile, web, tablet) all have different, but related, data needs. The prevalent way of talking to our servers is to use REST, but REST itself isn’t a very good query ‘or’ update language. It creates a lot of complexity that we have to deal with in order to do the simplest things. In the small, it is “easy”. In the large, it isn’t the best fit. Fulcro is more then that of course, but i found that bit to be very interesting. http://www.hyperfiddle.net/ I feel needs better docs, but i feel like there suggesting you can expose Datomics query language on the front end (and by extension to clients) instead of using REST. Anyone have any thoughts on either approach? One observation, imo is that both seem to trying to improve on REST.

i’m posting this then falling asleep. so if your ask me something directly ill probably wont respond tell tomorrow 🙂

Direct client-side querying is a growing trend across the board, as can be similarly seen in the push for GraphQL.

@fellshard Yeah, right. Right now i'm in a project where the UI directly queries Elasticsearch via HTTP for dynamic query screens. That decision was made before i came onboard driven from the UI team. I opposed, but now it is too late ☺️. It is a security nightmare. Especially if you need a more sophisticated security like dependant visibility or field-level access rules.

The UI team also argues they must be able to implement new query features fast without coordinating with backend. Thir shows the advantages of cross-functional teams ☺️

Yeaaah, you have to actually plan for it and coordinate it well, otherwise it's... a disaster.

It's naive to drive straight to the datasource itself, usually, unless you've actually designed security schemas etc.; and even then, you usually want a layer on top doing more interpretive work.

@fellshard @spfeiffer I think your both saying you need to take care with security concerns, if your going to allow client side querying. But its it really a different problem then when the work is split between been front and back? I imagine the best place for auth rules to exist is in the DB, not as constraints, but as part of a series of pre condition checks. That way data access is co located with the data, I guess this could also be an external service, but I'm hoping the co location might offer perf benefits.

@drewverlee If i forbid direct access from the client to the DB but route everything through a backend service i can enforce every security policy i like. And i can do client authentication via session cookie or JWT but still do DB access with a plain user/password to the database. I do not have to share my user database with the DB or restrict myself to security mechanisms my DB system offers.

@drewverlee Bear in mind that client code is directly readable so anyone with a browser can pick apart your source code and can craft their own queries directly against your datasources. No matter how much you "secure" your communications, JavaScript code is readable and, via dev tools, directly manipulatable.

@cbroski this is where i ask the question

Maybe I'm misunderstanding, but have - for example - Relational DB schemas fallen out of favor? (Not that I've ever seen a real project leverage them effectively, but wondering if that could be what you're looking for.)

iirc you can shape what data and functionality a given schema can access to a pretty fine level

But this is pretty much speaking from what I recall doing in my college course. 😅

not sure what you mean when you talk about a schema accessing data nd functionality. I think of schema as the contract to the db server on what the blueprint is. I dont think relational dbs (and schemas by extension) have fallen out of favor. Though we have better options then we did in the past. Though not as many new things as people might think…

It's a bad naming conflict, I agree, and it makes talking about this difficult, unfortunately. What I'm talking about might also be specific to T-SQL, under which case I'm pretty sure you can ignore everything I've said 😅 In T-SQL, you can grant or deny permissions for sets of operations - SELECT, DELETE, etc. - to different roles within the database. The client-side account could be given access to a client role, and have limited capacity to query the contents of the database; in effect, the database looks and acts much smaller to them, and they don't have the ability to see anything you don't want them to see. This same set of constraints could be equally applied by a service layered over the DB, but at the cost of making it much harder to write flexible queries on the front-end, unless you can implement something like GraphQL that restores query power at the cost of server-side complexity.

I'm seeing a variant in PostgreSQL as well - https://www.postgresql.org/docs/9.0/static/sql-grant.html

@fellshard Sure, you can do some level of security at the DB level but if the client needs write permission, then any write is possible within the constraints of that security (e.g., if a client app can update the user account table for your app, then a bad actor can perform any update on any row).

DB-level access controls just aren't powerful enough for most applications (IMO).

Quite true. Sounds like a case for CQRS. Or SQL triggers!!!! 😷

@seancorfield word! And even for read-only access, you have to jump through hoops to make sure no one can maliciously query data he may not see.

Elasticsearch has the possibility to do something like that: Mapping incoming requests to roles that ES can make sense of (by injecting a self-written JAR that implements a security realm) and can restrict access to rows and even fields based on said roles.

In our case, we are decoding a JWT Token and map roles to the request carrying the token. Still, we have to keep roles up to date, and we are complecting roles for business use cases with data access roles in ElasticSearch. I am no big fan of that concept, tbh.

But hey, i am not hired for the easy tasks ☺️

@spfeiffer Sounds like a nightmare! I would expect it to be easier to just go through a simple web app on the server for that sort of thing 🙂

No, the UI guys love querying Elasticsearch directly from the UI as complex as they want to without having to coordinate with the backend. But we have to pay that bill somwhere else.

I feel the overall effort would be lower using the traditional approach of enforcing security constraints in a backend service and querying the DB with a technical user, but YMMV. Decision was made before i joined the project. And CTO likes his elegant way of querying ElasticSearch without an additional backend service. I myself feel uncomfortable alone for exposing Elasticsearch to the net through the firewall at all. Every port beside 22 and 80/443 should be closed ☺️

@spfeiffer i think i understand the concerns. Do you think something like #fulcro’s data driven queries (similar to graph sql) offer a compromise? Its not quite the full database query language, but its more expressive and re-usable then REST.