We had an LiQL query we were using for years to surface community posts on our help center, and following the move to Aurora we need to update this to GraphQL. However, the developers on that team would prefer SQL/LiQL as their system is not set up for GraphQL.
Is it possible to still use LiQL or SQL queries while on Aurora?
Hi SheenaK - I don't believe this is possible, I'm sure some of the devs here might be able to help convert the query, can you share the LiQL query?
I have already converted the LiQL query to GraphQL, but our team internally can only use LiQL or SQL in their system. It appears that GraphQL is not universal to every system, whereas SQL often is, so this is probably going to be a point of frustration for a lot of people going forward.
If anyone does learn about a workaround, I'd love to hear it.
Aurora still supports the legacy REST APIs, although the url path needs to be updated to append /t5/s to hit those legacy REST endpoints. I assume your developers aren't directly using LiQL or SQL rather that they are using REST endpoints where they pass LiQL to execute a query and get a response. While the REST APIs are still available today with that URL change, they will be deprecated in a future release with plenty of prior notice given.
GraphQL is a query language but it still works through basic HTTP commands (post), the difference is you are passing along GraphQL queries in the request, often to a single endpoint, to request exactly the data you want returned. It's a more standardize structure to our proprietary LiQL queries. Outside of some helper libraries that making caching and state management easier, if any 3rd party app is making REST API calls, the transition to GraphQL API can use similar web/http requests. This can be experimented with basic web tools like Postman or even javascript fetch commands, curl etc.
the url path needs to be updated to append /t5/s to hit those legacy REST endpoints.
Okay, that could solve it, thanks! I'll relay it back to the team for a temporary fix, and then we can work on updating them to GraphQL properly.
The other thing to check with be how they are authenticating. Most likley they are doing a proper auth flow, but classic also allowed the session id cookie to be used for API auth which was not recommended but possible in older instances of classic. To further protect the API and data, Aurora does not allow this to be used to authenticate APIs requests.
Aurora still supports the legacy REST APIs
Good to know... 🤔
They replied to say "We are not using the REST API to get the results, we are directly querying the SQL from Java class."
is there an example set of LiQL -> graphQL query conversions anywhere?
I'm 99% sure they are using LiQL as we don't allow direct SQL queries even from Java in the application. LiQL looks deceptively like SQL even to the point of security teams raising concerns about direct SQL queries which should not be allowed that ended up being LiQL.
LiQL was created as a Lithium query language used to make it easier to query specific data fields from a REST endpoint. It was modeled after SQL queries but wrapped and limited queries to safe query parameters.
GraphQL is a more industry standardized API query language rather than a proprietary Lithium capability. GraphQL queries are still passed through typical HTTP requests and are basically wrapped REST API calls not all that different than anyone using REST/LiQL.
In your case, it sounds like the query is being made from a Java class. I assume this is a Java class you own and I assume it runs outside of the community application, so it should still be able to leverage LiQL for the time being and graphql in the future with minimal effort to update the query.
SheenaK see my response above, if you developers want to send over their query I'd be happy to review it. There wouldn't be any way for them to be making direct SQL queries against our database, so they are most likely making LiQL queries from the java class. If it's a liQL query its also very likely they are communicating over HTTP requests. GraphQL is a more industry standardized query language than LiQL, which is specific to Lithium Classic communities, both of which are wrapped around REST / HTTP queries to execute. Let me know if I can help review what is in use today and advise on mapping it over when the time is right (assuming the existing LiQL calls are working fine for now).
