API Endpoint for listing Actions

[hugbubby]

The codebase I use registers its actions with the hasura server every time it boots, based on the handler's function definition in the code and some additional metadata. This is to keep the definitions between the actions on Hasura and the handler functions in the codebase consistent, to provide "automatic" authentication of Hasura using unique header tokens generated at startup, and to prevent the code repetition and excessive type assertions that is normally required to handle HTTP action calls. When I remove actions from the action handler codebase, I run into a problem: some type definitions (like the type of the output often depend on that action) are no longer available, and when the codebase makes the set_custom_types API call at startups it panicks because of a metadata consistency error. This problem would be solved if we could just list all of the hasura actions the instance has at boot, so that the program would be able to drop the action that caused the error, but there's no API mechanism for our backend to do so. Alternatively, this would also be partially solved if there were some sort of "add" or "update" custom types endpoint that we could use to ensure the type-correctness of my actions on Hasura, instead of just a single set_custom_types endpoint that requires us to gather the output types of all of our actions across all action handlers at once. At the moment we have to manually remove the actions we've deleted in my code from the hasura instance, and a list endpoint would help me ensure that only the actions currently defined in my handler exist on the hasura endpoint.

[rikinsk]

@hugbubby As a workaround, it might help to use the export_metadata API to fetch all the metadata on the server which will contain the list of all the custom types and actions definitions. You can then use that to achieve the automation you're looking for.

[manasag]

Hi, I want to update that we are launching Hasura V3 (DDN) this month. In V3, actions can directly be integrated using our new Typescript connector which introspects your functions and automatically expose the graphql types and schema to Hasura (you don't have to manage manually). Also with CLI tooling, the metadata is deterministically owned and managed by you, and not the state of the server. This paradigm may help you setup your CI/CD and assert the state of Hasura is a much better manner.

I would highly suggest to join us to see the full power of Hasura DDN at the Hasura Dev Day on April 16 🎉. Sign up here: https://hasura.io/dev-day. Can't make it? Sign up anyway and we'll send you the recording.