Frontend Deployment for Add-API #269
Conversation
…nput values are accessible anywhere within the dashboard. Modified raisePR to send username aswell since we don't call convert on examples and the username doesn't get stored in the session, we have to manually pass it.
| @@ -0,0 +1,22 @@ | |||
| // GitHubAuthButton.tsx | |||
There was a problem hiding this comment.
Are all of the below permissions necessary? E.g. r/w access to private repos, and access to settings and deploy keys might be a security concern. Is there any way to reduce the permissions to follow least privilege?
Also, can the "API Generator" application be moved to be under the ownership of ShishirPatil/gorilla?
There was a problem hiding this comment.
No all of these permissions are unnecessary, I will updates this. And yea, Gorilla can take ownership, just create a new OAuth App and send me the Client ID and Client Secret, I can update the server and frontend with these new values.
There was a problem hiding this comment.
I was only able to reduce the scope of the OAuth app down to public repos. However, within this scope, the app is still authorized to perform read and write operations on:
- Code
- Issues
- Pull requests
- Wikis
- Settings
- Webhooks and services
- Deploy keys
Unfortunately, OAuth apps do not support more granular permissions for these; these permissions are bundled together with access to public repos by GitHub’s design. To address this, we could register a GitHub App for the Gorilla in the future, which has more granular permission controls, and rewrite the server to work with the Github App instead of OAuth
| username: 'user2', | ||
| apiName: 'API Two', | ||
| urls: ['https://example.com/api3', 'https://example.com/api4'], | ||
| urlsResults: {}, | ||
| }, | ||
| { | ||
| username: 'user2', | ||
| apiName: 'API Two', | ||
| urls: ['https://example.com/api3', 'https://example.com/api4'], | ||
| urlsResults: {}, | ||
| }, | ||
| // TODO: Add more examples |
There was a problem hiding this comment.
Should this be implemented/removed?
There was a problem hiding this comment.
Fixed, added more examples
| <div className="text-center mb-4"> | ||
| <h1>🦍 Gorilla: API Zoo Data Converter</h1> | ||
| <div className="text-center"> | ||
| <p className="lead">Easily give your API information to Gorilla API Store</p> |
There was a problem hiding this comment.
Maybe reword this to "Easily add your API information to Gorilla API Store"?
@ShishirPatil Also, should we use "Gorilla API Store" or "Gorilla API Zoo"? I think it would be good to have a consistent name.
apizoo/app/package-lock.json
Outdated
There was a problem hiding this comment.
This is a question of whether we want to prioritize minimizing the probability of a dependency conflict or bloating the repo with metadata, but in my PR for the API Zoo I specifically removed the package-lock.json to not add this huge file (12k lines!). I think the chance of dependency conflict for this simple webpage is quite low, and the package-lock.json file can be generated using the package.json file by running npm install. What do you think?
There was a problem hiding this comment.
Yea that's fine we can remove it. I did get some dependency conflicts from your repo, but they can just be fixed with npm audit fix I guess
This PR provides a web application for fetching API calls from a API documentation urls into a specified format (Option 1), to easily generate training points to train a fine-tuned LLM model in performing API calls.
Here is a short demo of the webpage: link