Hi,
I need some direction here, if anyone can assist me. I am not sure if this is the right platform.
Here is my problem statement:
I have an existing Phoenix Project (Pure API project without UI). I have a controller and an action which is called whenever a POST request is received with certain parameters.
There are around 5 to 6 plugs which get called before it comes to the action method in the controller.
Now, I currently use POSTMAN to make POST calls to this API. However, in POSTMAN, there is no validation for the parameters which are passed as a body to this POST request.
This is where GraphQL comes in. I am thinking about using GraphIQL as an alternative to POSTMAN so that I can get introspection, autocomplete and validation.
Now, I have setup Absinthe and got to the point where the resolver method gets called for the GraphIQL request. Now, the question is how do I exercise the Controller Action from this resolver. Note that my GraphIQL request should also go through the 5 6 plugs and then go to the controller action. The controller action will return back the output to the GraphIQL web interface.
My utmost priority is auto-complete and validation for my Phoenix APIs.
Can anyone please point me to something which help me achieve this?
My utmost priority is auto-complete and validation for my Phoenix APIs.
So it sounds like you want to keep your APIs in their existing REST format (and not use GraphQL queries/mutations)?
If your answer is “yes”, I don’t think GraphiQL is intended to do what you are asking. It is intended to help you explore the structure of GraphQL queries/mutations.
In terms of “validation” for you Phoenix API’s, would writing controller test(s) satisfy the validation requirement? You specify certain parameters are passed in and the test passes if you get a successful response based on the parameters.
Hopefully I’m understanding the context of your question correctly, if I am not, please feel free to correct any mistaken assumptions.
Yes, I think you have got my use case almost correct.
Yes, my interest to that question is Yes. At this moment, I am not looking at modifying my existing REST APIs because that would require a lot of effort.
I could give it a try later on.
For now, I am just looking at providing autocomplete feature which is provided by GrahpiQL.
Also, the unit tests won’t work because, I’m intending this to be used by the front-end team who does not have access to the code base.
The only problem I am looking to solve right now is that the front-end guys are assisted as to what my backend API expects. This is a huge problem since there are a ton of possible keys which could be passed to my API. Currently, the backend guys have to communicate this verbally to the front-end guys about the request format which the API expects. This is kind of a hassle and I am looking at GraphiQL to solve this problem.
Let me know if you need more context and any suggestions you might have.
Currently, the backend guys have to communicate this verbally to the front-end guys about the request format which the API expects.
So it sounds like the real problem you are trying to solve is documenting your REST API for the front-end team, yes? If that’s the case, I can think of a couple of possibilities:
You can try to wrap your REST API with GraphQL - https://graphql.org/blog/rest-api-graphql-wrapper/ (based on my understanding of your issue, this sounds like a short term band aid that won’t work too well over the long term unless you can transition over to GraphQL and some other things happen with the way the team documents things I’m guessing)
Consider using something like swagger for Phoenix to document (autogenerate documentation) your REST API so your front end team can have documentation to look at instead of pinging the backend team all the time
Not sure about how your API is setup with respect to it expecting a “ton of possible keys” but if it’s possible, it may also help to restructure your API so there are a limited number of permutations of possible input data sets to each REST endpoint rather than a “ton of possible” keys. But I obviously don’t have any contextual experience with your current setup/tooling/needs.
