sasswart / can Goto Github PK
View Code? Open in Web Editor NEWGenerate Go gin servers from OpenAPI specs
License: MIT License
Generate Go gin servers from OpenAPI specs
License: MIT License
We currently only accept .yml
files.
Function names are informed by the content in the make file. A path of items/:item_id/thing
currently produces function names that substitute out the colon for an additional underscore and accept the underscore present in the path parameter. This breaks go function name guidelines.
We're currently wrapping paths in filepath.Clean()
in the hopes that the filepath package will handle a lot of the os-specific path formatting. This isn't thoroughly tested and we should adopt the community best practice on how this should be done.
Generate and compile a binary from go code that will allow for an easy interface with any server created by can. This could be done in golang through the use of cobra-cli
Without this, the entire gin-in-a-can repository must be cloned for it to be useful.
OpenAPI files are read and parsed in the openapi package.
The generator should not know about them.
The generator knows how to take its data and put it down as a template.
Quality of life improvement.
This will allow for the common pieces of successive generations to remain in similar places, making diffs easier to read over incremental changes to source files
This would allow the application to be plug and play for most applications that fit it's initial use case.
Alternatively one could hardcode the config file and allow for a template to be sent to stdout for capture by the user intending to set their own config to feed in via the intended CLI flag
We don't currently generate the Response Type and GetStatus() method for a 204 no content responses. This breaks code that requires the 204 response to be checked and currently fundamentally breaks this functionality
Schemas do not have names in the OpenAPI Spec.
Model objects in code need names.
Name inference therefore needs to be a thing.
The most obvious name inference rule is to sanitise $refs into model names.
Unfortunately, they are not always available.
This is necessary in order to be able to integrate gin-in-a-can into ci pipelines where the config file might be part of a different repo in a different directory.
This config will produce a broken models package:
openapi: 3.0.0
paths:
/heartbeat:
get:
responses:
200:
description: "Serves the API's documentation"
content:
"application/json":
schema: {}
info: {}
Currently unsupported and would improve our coverage of the OpenApi specification if we were to support it.
domains:
type: array
required: [domain]
items:
type: object
required: [name, enabled]
properties:
explicit_domain_id:
type: string
id:
type: string
name:
type: string
description:
type: string
enabled:
type: boolean
An open api definition such as this does not cause the generated code to omit the omitempty
json tag for the domain, name, and enabled fields in the generated structs.
We generate a base Struct that represents an unimplemented server from which a concrete server can be composed.
This unimplemented server currently returns the status code defined by InvalidRequestStatus
in the config file.
This should change to a config option called UnimplementedResponseCode
and a model should always be generated for it for every request.
Consider grouping multiple function signatures into their own path-named interface. This will allow the Server
interface to remain uncluttered as it can be composed by-endpoint as opposed to including every signature definition.
type Server interface {
DomainDelete(*gin.Context, *models.DomainDeleteRequest) models.DomainDeleteResponse
DomainGet(*gin.Context, *models.DomainGetRequest) models.DomainGetResponse
DomainPatch(*gin.Context, *models.DomainPatchRequest) models.DomainPatchResponse
DomainPost(*gin.Context, *models.DomainPostRequest) models.DomainPostResponse
ProjectDelete(*gin.Context, *models.ProjectDeleteRequest) models.ProjectDeleteResponse
ProjectGet(*gin.Context, *models.ProjectGetRequest) models.ProjectGetResponse
ProjectPatch(*gin.Context, *models.ProjectPatchRequest) models.ProjectPatchResponse
ProjectPost(*gin.Context, *models.ProjectPostRequest) models.ProjectPostResponse
ProjectListGet(*gin.Context, *models.ProjectListGetRequest) models.ProjectListGetResponse
}
type Server interface {
DomainInterface
ProjectInterface
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.