Elm-open-api v0.5.0

Show and Tell
1

A new major release of elm-open-api :tada: thanks in large part to @miniBill.

Added

  • Support for API Keys in auth
  • The new option --effect-types for determining which http effect types are generated
  • The new option --server for being able to pass in a server URL to be used in the generated requests

Changed

  • Now generates 4 files instead of 2:
    • <namespace>/Api.elm, <namespace>/Json.elm, and <namespace>/Types.elm which correspond to the OAS directly
    • OpenApi/Common.elm which can be shared across all generated SDKs

Most of these are quality of life type changes, like only generating 1 copy of OpenApi.Common if you generate multiple SDKs and separating out the Json and Types modules (handy if you’re only using this for JSON Schema work).

The more significant part of the release is the new --effect-types option. Instead of generating all of Http.request, Http.riskyRequest, Http.task, and so on you now by default only get Http.request and Http.task. To get only Http.riskyRequest you would pass in the option --effect-types=riskycmd. To get both risky functions you’d pass in --effect-types=riskycmd,riskytask.

Here’s where this is really nice, you can also pass in --effect-types=backendtask to generate an SDK that’s compatible with elm-pages! This is the first of the non-core pages to be supported, and the changes to codegen mean we can much more easily add support for other packages, like andrewMacmurray/elm-concurrent-task.

15 Likes
2

This is fantastic timing, I’m working on a new webapp at the moment with a FastAPI backend, which is OpenAPI compliant. Looking forward to trying it out!

1 Like
3

Please report any issues you encounter! Always trying to make it a better experience to use

1 Like
4

This tool is working really well, it’s generating Elm API code that’s very logical. Thanks very much for this! The only issue I’m having is that I’m using Oauth2 for authentication and I get a warning: Warning: Unsupported security schema: Oauth2 at /users/me/ -> GET. My security section of my openapi schema file looks like this:

    "securitySchemes": {
            "OAuth2PasswordBearer": {
                "type": "oauth2",
                "flows": {
                    "password": {
                        "scopes": {},
                        "tokenUrl": "token"
                    }
                }
            }
        }

I’ve used the recommended method for authentication in the FastAPI docs, but I’m not sure if I need to customise the code to get a security schema that elm-open-api understands. This isn’t a major issue, I can just use the generateTodos flag and then go in and change the function to accept the token in the arguments and then use it to set the auth header. Saying that, most of my endpoints require authentication, so it’s a bit of a pain. Do you know if there’s a way I can make this easier for myself?

5

It can be easier if I implement that branch of code :sweat_smile:

If you have the time, would you mind filling out an issue here Issues · wolfadex/elm-open-api-cli · GitHub with what you’d expect the output to look like and include that little section of the schema?

I can try and take a look at it this week, though no promises on timing.

1 Like
6

Brilliant, thank you so much for helping! I’ve made an issue on GitHub (OAuth2 Security Schema Code Generation · Issue #100 · wolfadex/elm-open-api-cli · GitHub) and tried to include as much information as possible. Please let me know if I can do anything else to help.

7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.