Which datastores support JSONata queries?

[jugaadi]

Couldn't find much information about it. How is it being used in production?

[andrew-coleman]

The following (that I know of) are using JSONata in production:

• IBM App Connect. JSONata was created for this product and was engineered to be production ready before it was even open-sourced.
• elastic.io uses jsonata as the expression language for their data mapper
• nchannel use it for mapping as well

It is also used as the expression language in Node-RED, which I know is used in a number of production environments.

[zubairov]

Just to add what @andrew-coleman said we at elastic.io run ~10M containers per month avg. 30% of these containers are with JSONata inside :) so can confirm it's rock-solid

[jugaadi]

I've personally used it and found it to be great. I have tried to spread the word(Eg. https://github.com/json-api/json-api/issues/1272), etc. Though I strongly feel that it is currently under-marketed even though two big companies are driving it.

@andrew-coleman Few doubts:

1. Do you think it could be used as a QL(CRUD) for JSON data stores?
2. Is SQL feature parity or compatibility (in JSON context) in the roadmap?
3. What are you thoughts on GraphQL and JSONata as an alternative to it?

@zubairov Thanks for the info. We should update these info in the main website.

Few thoughts:

1. Would be better if spec repo is separated from implementation. Gives more clarity to the end user.
2. Discord might be a better alternative to Slack with all the joining issues.
3. Blogs(medium, etc) section should be added to the website wherein more usage related blogs/videos/etc from IBM and Elastic are posted. Will be a huge confidence booster for the rookies out there.
4. A twitter handle would also be appreciated.

Let me know if I can help in any way.

PS: Please add me to Slack.

[andrew-coleman]

Thanks @jugaadi

Do you think it could be used as a QL(CRUD) for JSON data stores?

Yes, I see no reason why not. XQuery has been used in that way for XML data stores.

Is SQL feature parity or compatibility (in JSON context) in the roadmap?

JSONata was inspired by the syntax and semantics of XPath/XQuery rather than SQL. It depends what features you are referring to. They are both query languages with the select -> filter -> map -> reduce programming paradigm. The join semantics of SQL are much stronger, which is more important for SQL given the nature of the data structures.

What are you thoughts on GraphQL and JSONata as an alternative to it?

There is plenty of overlap, but they are designed for different needs. JSONata is an embeddable Turing-complete expression language designed to extract and manipulate values from JSON documents.

Would be better if spec repo is separated from implementation. Gives more clarity to the end user.

I haven't written a formal spec (yet), so the specification is split between the test suite and the documentation. The test suite is implementation agnostic so could be split into a separate repo. The docs are already in a separate repo

Discord might be a better alternative to Slack with all the joining issues.

Perhaps, but everyone I know uses slack.

Blogs(medium, etc) section should be added to the website wherein more usage related blogs/videos/etc from IBM and Elastic are posted. Will be a huge confidence booster for the rookies out there.

Yep, the website has been neglected (as well as the docs). If you would like to help out, then writing blogs, how-to articles, improved docs, etc would be very gratefully received.

A twitter handle would also be appreciated.

jsonata

PS: Please add me to Slack.

Sure, please send me your email address and I'll add you.

[xogeny]

@jugaadi, a few comments from my end.

First, with respect to GraphQL, you might find this talk that I recently gave a RESTFest interesting.

Second, I am of the opinion that it should be possible to use JSONata expressions to make direct queries on databases. What I mean by that is given a JSONata AST, it should be possible to transform it into a native query for SQL and noSQL databases. I haven't proven this out just yet, but I've been doing some work trying to enable that. So far, that work is not completed.

As for blogs, etc. see the talk referenced above.

Finally, for specifications, I'd love to see something don in SPEC.md.

[jugaadi]

@andrew-coleman Yes. I would love to contribute. I have created a Twitter account and Medium publication for the same. As the language creator, it would be great if you can write the introductory blog post. Also looking forward to @zubairov and @xogeny to post their experiences. We can also plan a series of blogs and make developer onboarding easier. I personally think that JSONata has the potential to become a great alternative to GraphQL or even SQL.

@andrew-coleman A formal spec is very much needed to bring more clarity to the new users. Examples: GraphQL , JSONiq.

@xogeny Excellent talk. Can you share your slides?

Would love to hear everybody's opinions, ideas, etc on how to move forward and build an awesome community.

[andrew-coleman]

@jugaadi While I appreciate your enthusiasm to contribute, it would appear that you have just given me a to-do list, and I already have one of those.

As far as blogs are concerned, blog authors will probably already have their favoured hosts. I use developerWorks to host mine, including an introductory one here. Likewise, elastic.io have published a number of articles in their preferred place. A number of videos have also been published (e.g. here, here, here).

I'm not sure what you plan to do with the twitter account you have created. You seem to have used the JSONata name and branding as if this was owned by jsonata.org, which it isn't. Please don't do that.

Please don't take this the wrong way, I genuinely do appreciate your desire to contribute, but I was hoping more for articles hearing about your projects using jsonata rather than project managing others.

Thanks again!

[jugaadi]

While I appreciate your enthusiasm to contribute, it would appear that you have just given me a to-do list, and I already have one of those.

Sorry for the misunderstanding. It was never meant to be a to-do list. The spec(with versioning) was just a suggestion and the introductory blog post was just a request as the first one was written 2 years ago.

As far as blogs are concerned, blog authors will probably already have their favoured hosts. I use developerWorks to host mine, including an introductory one here. Likewise, elastic.io have published a number of articles in their preferred place. A number of videos have also been published (e.g. here, here, here).

As someone new to JSONata, I've personally found it difficult to google each time for any new references even though it is scattered across the wild web as you have pointed out. It was a similar experience for others in my team. A communication through Twitter or a repost of the original content in Medium would have made developer onboarding easier.

I'm not sure what you plan to do with the twitter account you have created. You seem to have used the JSONata name and branding as if this was owned by jsonata.org, which it isn't. Please don't do that.

The twitter account was meant to be used for broadcasting the happenings in the community similar to GraphQL. Wasn't aware of the ownership though it was meant to be handed back to the community. I'll delete it anyways.

Please don't take this the wrong way, I genuinely do appreciate your desire to contribute, but I was hoping more for articles hearing about your projects using jsonata rather than project managing others.

My agenda was never to project manage others. I took the initiative to contribute towards its growth so that it benefits all and strengthens the community further.

[andrew-coleman]

That's cool, we're on the same page then. As I say, I'm very happy that you're prepared to contribute.

Interesting to hear your perspective on the importance of a formal spec. From my experience of specifications, they are very important for implementors, but less useful to beginners trying to learn a technology. Even for implementors, the measure of conformance to a spec is done by running a test suite. Indeed, many standards bodies will not endorse a spec until enough implementors have demonstrated they pass a conformance test suite (see XQuery conformance report, for example). So given that, together with the limited time I can devote to this project, I have prioritised a high quality test suite over a formal specification.

But I take on board your observation about lack of material for beginners. I'd really like to make substantial improvements to docs.jsonata.org and make that the 'go to' place for all these issues. For that it requires a better layout and much more content, including concepts, tutorials, samples, case studies, improved reference material, etc, etc. It's in this area that I really need help and would be hugely grateful for any time you could devote to this. The docs site is in this repo and uses Jekyll (but I'm not wedded to this - open to other ideas) to generate the site from markdown documents.

[jugaadi]

Let me know your plans about docs. Willing to help in my spare time. Also share any existing docs wrt concepts, case-studies, etc so that I can understand the usage further.

PS: I asked for a spec from an implementor's perspective. It is important that I first understand the design before venturing into implementation. Need to convince my employer about its value in terms of design and community support before going ahead.