I’d say it’s apples and oranges. SQL is a great DSL for a very specific context (relational databases), with some rather conspicuous issues/limitations (string ’’orientation”, etc)]. What pathom, and GraphQL (to a lesser degree) provide is a similar capability for a far more generic context

@eoliphant that was my initial reaction as well but after thinking about it I disagree that it’s apples and oranges. In Om.next David Nolen referred to the idea of “messages” and “interpretation”. A message is the bag of information (the request) that a client submits to the server, and “interpretation” is the process in which this bag of information is, well, interpreted to fulfill the client’s demands. You could start with very simple messages, such as “give me all users”, which wouldn’t be much different from a route in a REST API. You can then build more complex messages, such as those that Pathom interprets, which allow you to specify selections on fields, etc. There is, however, nothing stopping you from taking this further. Say you have a resolver to get a list of users filtered by name. You could imagine embedding a filtering DSL there, to filter by any arbitrary field with a semi-arbitrary condition composed of some primitives. Etc. If you went down that road you might end up with a language that, while not being SQL, gives similar powers to the client (almost arbitrary querying of your data)

@eoliphant does this make sense? 🙂

hmm. fair point i think. But then is it just a matter of say pathom in particular perhaps being a ‘better’ apple? 🙂 particularly in the clojure(script) world where it’s yet another expression of ‘doing stuff with data’ and there can be a pretty short ‘distance’ between EQL and however you’ve decided to implement resolvers when they are themselves ‘clojury’?

@eoliphant Yeah… I mean, I use Pathom, have used GraphQL and I get why, on an intuitive level, it is better to limit the power of such a language. But I don’t feel I have a very strong argument to answer people who bring up the above point on SQL

> how is this any different than the reason why SQL was created 40 years ago (allow clients to request data in a flexible languager) It's not? It has better semantics for graphs but it's still a query language. But it's also a recursive data based query language, which makes it easier to break it apart for later recomposition. This is not as straightforward in SQL/GraphQL (even with fragments). > and why wouldn’t we then let clients run SQL queries directly? I'd say security and performance. You're the one that has to writing the executor/resolver/etc of the query "nodes", so you only give access to a blessed subset/family of queries. (e.g. a user can't poke at other user's data, a user can't perform an expensive search). Opt-in vs opt-out. You could argue that this would also be doable in a SQL system with some code, just a tad more annoying. I agree, but I'd expect a good amount of friction given the original design goals of the system/language.

@hmaurer hello 🙂 ok, let me tell you how I see SQL in comparison with EQL, to start what is similar I think we can say that both are a way to describe information requests. Besides that there are some significant differences: 1. SQL outputs are tables, EQL outputs are trees. This is a very big difference, in SQL you can't describe nested structures, you can try faking it by adding extra columns but that goes off trace quickly, while EQL/GraphQL have in their core the ability to describe nested structures, that's one important reason why I think SQL is not suitable for user interfaces, imagine trying to write a single SQL query to describe a complex SPA data requirement with many deep levels of structure. 2. SQL is implementation specific, although some features of SQL have shared syntax, going from Postgres to Oracle, for example, can quickly break your queries, so its not in SQL nature are all to describe generic data structures, its about specific tables in a particular system, not for systems integration (which is what EQL / GraphQL does). 3. SQL has powerful aggregation tools, which can be good for reductions and processing, but are hardly so useful as an API, were you want more fined control of what are been exposed, if we go in this direction SQL and EQL are very different things with different goals 4. SQL is a text format (like GraphQL is too) while EQL is data-oriented (based on EDN). This allows easy of processing of a data format instead of having to deal with a new language/parser, this makes easy to write more generic operations since the requests are easy to manipulate.

Thanks @wilkerlucio!