alex-glv: I wouldn't say that you must use om on the backend, just that it's a more seamless integration. I'm using om.next with python on the backend; I wrote a parser for the om.next query syntax with the help of transit-python

Ultimately, it may be possible to translate om queries into graphql syntax. That would be ideal for this kind of integration.

I say that simply because graphQL is more popular and if you intend to expose the API to third parties, you probably want a graphQL API. Saves maintaining a special 'om' api if this were possible.

yes, the remote is totally custom, so sending the query to a om.next parser on the server is just one option, you can parse on the client and send as REST requests or whatever you want (I made implementations that worked using local indexdb database, no backend at all)

about the parser implementation, I made a blog post with some tecniques for implementing that, you might find some useful information: https://medium.com/@wilkerlucio/implementing-custom-om-next-parsers-f20ca6db1664