Generate OpenAPI Client using MIT Open's OpenAPI Spec

[ibrahimjaved12]

What are the relevant tickets?

Part of https://github.com/mitodl/hq/issues/2426

Description (What does it do?)

Generates OpenAPI Client using MIT Open's OpenAPI Spec, mentioned here: https://github.com/mitodl/hq/discussions/2536#discussioncomment-7340206

Screenshots (if appropriate):

• [ ] Desktop screenshots
• [ ] Mobile width screenshots

How can this be tested?

Additional Context

[github-actions[bot]]

Netlify Deployments:
www: https://ocw-hugo-themes-www-pr-1284--ocw-next.netlify.app/
Course v2: https://ocw-hugo-themes-course-v2-pr-1284--ocw-next.netlify.app/

[pdpinch]

@gumaerc @rhysyngsun do you think this PR should go into a new repo?

[gumaerc]

@pdpinch @ibrahimjaved12 After looking this over from the perspective of how we might use it to accomplish generating the OER commons CSV, I'm not so certain that we should be making these API calls from the theme using Javascript. Looking at the example code in openapi-client-example.ts, I'm not sure how we're going to accomplish generating a CSV that is available at publish time. Javascript code in this repo executes on the client. Since there is no web server, there would be nowhere to save the CSV file upon generating it. We might be able to create an HTML page containing some JS that would fetch the data, generate a blob, then generate a link to that blob that could be clicked by a user to download the CSV, but that doesn't sound like what we want. I think what we're looking for here is a CSV that is published along with ocw-www and is always available at a given URL, i.e. https://ocw.mit.edu/courses.csv or something similar.

I realize that we want to generate this data using the new Open API, but I feel like I should bring up again that we already have this data in the ocw-www content repo: https://github.mit.edu/mitocwcontent/ocw-www/tree/main/content/websites. Before the new API was available, we added code to ocw-studio that generates a WebsiteContent object of type website for each Website object that is not the root website. These new WebsiteContent objects are associated with the root website, denoted by ROOT_WEBSITE_NAME and are published along with its content. The reason I bring this up is to ask if we are unnecessarily re-inventing the wheel here? Is there data within the Open API that we will need for generating this CSV that doesn't exist in ocw-studio?

I feel that we should at least have a consistent way within the www theme to iterate a list of courses, whether we use the Open API or not. If we're going to use the API, we should also use it to generate the offline index. Otherwise we will be using 2 completely different methods to accomplish the same task, which is to fetch a list of courses and generate content based on that.

Hugo does have a way to hit an API at build time, but not using Javascript. If we wanted to do this, we would need to use resources.GetRemote. This way, the data would be available at build time and the CSV file could be generated along with the rest of the site. In order for that to work, we would need a direct URL to hit the API on and could not use a Javascript wrapper to generate the API request.

With all this being said, I'm sure we will have reason in the future to hit the new Open API from the frontend. In which case, we will need the Javascript code in this PR, but I do think it should be checked into a separate repo and published to NPM as a library. That way we could simply add it as a dependency here and import it, keeping things clean.

[pdpinch]

Thanks @gumaerc. I don't think the three of us are on the same page here, but I'm pretty sure that this PR is not the approach we should be taking. Let's put this on hold until we can discuss more -- either over Zoom or in a RFC.

[pdpinch]

@ibrahimjaved12 this can be closed right? We ended up doing this in another repo I think.

[rhysyngsun]

We have this published as an npm package now: https://www.npmjs.com/package/@mitodl/open-api-axios

[ibrahimjaved12]

@pdpinch Closing this as we ended up creating ocw_oer_export for this instead.