Current status?

[vorce]

Hey. This looks very interesting and I would love to use something like this. I'm curious about the current status and what the plan is going forward. Will you publish it to hex.pm when you have a first release?

Anything you want assistance with? I would be glad to contribute.

[vic]

Hey Joel !

Thanks for your interest on swagger-elixir, sorry for the late response, I'm currently trying to find some spare time for my OSS projects, but sure thing I want to make this project something useful and I'll keep improving it whenever I can. - At least two other people and a friend of mine (@davoclavo) have shown interest on this project so I'd like to somehow speed up things a bit on this project, I'm truly trying to find some time for it, just I've been busy with life/work lately.

Yes, I'm planning on publishing it on hex.pm once it's usable, here's a roadmap/vision of features I'm planning. It's pretty much in its early stages so if you want to help with some ideas, feedback or code, you are more than welcome :).

v1.0.0 roadmap:

Swagger Client

Vision

My idea is, having a swagger.yaml file, either have a code generator like

# Generate modules namespaced with MySwaggerClient that can talk to
# a remote API as specified by the yaml/json file. If you look at the source, there's a bit of
# base code for this.
mix swagger.gen.client MySwaggerClient my-swagger-api.yaml

or - mainly for use cases like tests and one-off client where you dont need to customize the generated code -

defmodule MyClient do
  use Swagger.Client, swagger: "path/to/swagger.yaml"
end

Both basically do the same, except the mix task actually generates source code inside your project for you to change as suitable.

Roadmap

[x] parse the yaml/json file into an Elixir map/struct to be consumed by code generator. [](in progress) generate modules for param object types from the swagger definition Currently my idea is to reuse vic/params for this. Missing work here is for every referenced param (on headers / path / request body) generate a module with the correct params schema. [] same as previous point but for response objects. [] Generate a set of modules (many other swagger code generators use tags to divide endpoints into modules) that use HTTPotion and given some Params structs set them on the correct header/path/request-body to be sent. Receive response and convert into response structs.

Swagger Server

Vision

As with the client, I'm planning on having both a code generator and a use Swagger.Server alternative. My idea here is for each endpoint generate a plug that is able to parse the parameters from headers/path/request-body and forward them (as a Params struct) into a backend module. This backend module can be swapped (and by default generates just dummy data, so that having a swagger file can give you a fully functional server that returns dummy responses - in swagger you can specify have example requests and responses) or you can actually specify some modules from your app that actually implement the required backend logic. Of course having plugs here would make it very easy to mount them as routes on a Phoenix app.

Roadmap

[x] parse the swagger definition [x] Params structs and Response structs are the same as those needed for client, so implementing them gets this done. [] For every endpoint generate a plug that can fill corresponding Param structs from the plug's conn. [] Handle it to some other module (by default the dummy response) [] Let user specify modules to handle logic instead of the dummy one. [] Use examples/pet-store.yaml and generate an example project (another github repo) on how to mount it as a swagger server with Phoenix.

That's what is currently on top of my head, feel free to share your opinion and what you'd like swagger-elixir to be.

[vorce]

Wow, thank you so much for the very informative reply. The server part is where I'm especially interested. I think what initially attracted me to the project was the idea of something not tied to any specific framework (and going further; have reasonably few dependencies). Overall I really like the vision.

And I can totally relate to feeling like you don't have/spend enough time on OSS projects. I'll keep a close eye on this one and might send a PR if I feel like I can contribute. Cheers!