gerlowskija opened a new pull request, #2050:
URL: https://github.com/apache/solr/pull/2050

   https://issues.apache.org/jira/browse/SOLR-17062
   
   
   # Description
   
   Currently, Solr only offers one "first-party" client, SolrJ, which can only 
be used within JVM environments. This is obviously limiting for our users.
   
   Historically, keeping client bindings in multiple languages up to date has 
been too daunting for the project to undertake. But now that Solr produces an 
OpenAPI spec for its upcoming "v2" API, we have the ability to generate client 
bindings from that for a variety of languages with very little additional 
maintenance cost.
   
   There's extra incentive for us to experiment with languages that we 
ourselves use internally, as that gives us the opportunity to vet/dogfood the 
generated clients in our own code.
   
   # Solution
   
   This PR uses the 'openapi-generator' gradle plugin to create a Javascript 
client based on our OpenAPI spec. A few details:
   
   - `./gradlew solr:api:buildJSClient` to generate the client
   - We're relying on the OpenAPI Generator project's 
'javascript-closure-angular' generator here, but there are other options 
available if this is a bad fit.  In particular, the project offers a vanilla 
'javascript' generator which might serve us better?
   - The generated client only supports those APIs that are represented in our 
OpenAPI spec - i.e. the v2 APIs that have been converted to JAX-RS. Currently, 
this is limited to select admin APIs.  Users that cannot find an API they'd 
like should consider migrating the code for that API to JAX-RS.
   - Once created, client is available at `solr/api/build/generated/js`.  Not 
sure how packaging works in Javascript code, but the generated code doesn't 
appear to be packaged in any way - it's "just" a bundle of JS files.
   
   
   # Tests
   
   The code-generator has an option to generate tests for the generated client 
code. I've disabled that currently, trusting the generator to do its thing, but 
we can enable that if it's something we'd feel more comfortable using.
   
   # Checklist
   
   Please review the following and check all that apply:
   
   - [x] I have reviewed the guidelines for [How to 
Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms 
to the standards described there to the best of my ability.
   - [x] I have created a Jira issue and added the issue ID to my pull request 
title.
   - [x] I have given Solr maintainers 
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
 to contribute to my PR branch. (optional but recommended)
   - [x] I have developed this patch against the `main` branch.
   - [ ] I have run `./gradlew check`.
   - [ ] I have added tests for my changes.
   - [ ] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to