Generating Go code for the API server

[ernesto-jimenez]

schematic works nicely when creating a client.

I think it might be cool to consider generating code for the server too.

The bare minimum would be generating the response structs to serialize responses.

A more ambitious goal would be to generate the main boilerplate to serve the HTTP API: http handlers, helpers to parse requests and render responses, etc.

Maybe even doing something like this:

package main

import (
  "http"
  "github.com/whatever/api/server"
)

func main() {
  // NewHandler takes an object that implements server.Handler and returns an http.Handler
  // server.Handler is generated by schematic and it has one method for each link in the Schema
  h := server.NewHandler(backend{})
  s := &http.Server{Addr: ":8080", Handler: h}
  s.ListenAndServe()
}

[cyberdelia]

Also something that could be achievable is to allow to generate the schema from Go code.

[j]

+1

[ant0ine]

+1

It would be great to split this package in two parts. First, a generic JSON Schema implementation, then the client code generator. That would allow people to easily reuse the first part to generate server implementations.

[ernesto-jimenez]

FYI, there's a new project called goa that generates JSON Hyper Schema from Go code and also generates all the scaffolding to serve the API so you can focus on the business logic.

http://goa.design/index.html

[KellerFuchs]

@ernesto-jimenez As far as I can see, though, goa is monolithic, in the sense that it's not possible to generate only the server scaffolding, based only on the hyperschema: the only possible input is goa's own DSL.

[ernesto-jimenez]

@KellerFuchs goa allowed you to generate de JSON Hyper Schema from their DSL, and then you could ideally other tools to generate the client. I believe since my comment back in December goa favoured Swagger more instead, but have not checked it recently :)

[KellerFuchs]

@ernesto-jimenez Yes, but this doesn't cover at all implementing an existing Hyper-Schema, or simply wanting to model the API directly during the design phase.
Anyhow, I will likely have a stab at implementing this.