Generate:

• Init server + controllers for endpoints
• Typescript fetch functions with type-checked payloads for generated endpoints
• SQL files with tables and queries for controllers ( Postgres )

from one config file.

1. Either create a custom config file with the frontend editor or copy one of the config file from examples dir

2. Install gomarvin

# go version >= 1.17
go install github.com/tompston/gomarvin@latest

# go version < 1.17
go get github.com/tompston/gomarvin

# or clone the repo and run go run main.go
git clone https://github.com/tompston/gomarvin.git

3. run gomarvin

# run this in the same dir as the config file, if the name of the config is "gomarvin.json"
gomarvin generate

# run this if custom config file name or path
gomarvin -config="PATH_TO_CONFIG" generate

# or generate only the typescript API client file. Useful if you want to generate fetch
# functions for a pre-existing REST API in a fast way.
gomarvin -fetch-only="true" generate

4. run lower commands

cd GENERATED_SERVER
go mod tidy
go mod download
go run main.go

Flags:
  -config		Specify path to the gomarvin config file (default "gomarvin.json")
  -dangerous-regen	Regenerate everything. If set to true, init server will be regenerated and all previous changes will be lost (default "false")
  -fetch-only		generate only the typescript file that holds fetch function (default "false")`

// import the generated file
import * as F from "../../../chi_with_modules/public/gomarvin.gen" 
// or just import a single fetch function
import { GetUserById } from "../../../chi_with_modules/public/gomarvin.gen"

// either use the default client created from
// the settings of the config file, or create a new one
// (useful when switching environments)
const defaultClient = F.defaultClient

// api client when deployed
const productionClient: F.Client = {
  host_url: "http://example.com",
  api_prefix: "/api/v1",
  headers: {
    "Content-type": "application/json;charset=UTF-8",
  },
}

const DEV_MODE = true

// switch to productionClient if DEV_MODE is false
const client = DEV_MODE ? defaultClient : productionClient

// fetch GetUserById endpoint
async function FetchGetUsersById() {
  const res = await F.GetUserById(client, 10);
  console.log(res);
}

// append optional string to the existing endpoint url
async function FetchEndpointWithAppendedUrl() {
  const res = await F.GetUserById(client, 10, { append_url: "?name=jim" });
  console.log(res);
}

// define custom options for the fetch request
async function FetchEndpointWithCustomOptions() {
  const res = await F.GetUserById(client, 10, { options: { method: "POST" } });
  console.log(res);
}

// Use both optional values
// - append a string to the fetch url
// - define a new options object used in the fetch request
async function FetchWithAppendedUrlAndCustomOptions() {
  const res = await F.GetUserById(client, 10, {
    options: { method: "DELETE" },
    append_url: "?name=jim",
  });
  console.log(res);
}

• Seeding the db

  • As the generated fetch functions are mapped to the endpoints, you can use them to seed the database pretty easily. Using deno with the faker package can make the process trivial.

• If formatting does not work for some reason, run this

  gofmt -s -w .
  

• Using the tool to generate fetch functions for pre-existing REST APIs

  • If you want to generate a client for an already existing REST API in a fast way, you can use the editor to document the needed values to codegen the fetch functions in a fast way

  # run this after exporting the config file, assuming that
  # the gomarvin.json file is in the same dir
  gomarvin -fetch-only="true" generate

• If there are errors after creating a new config file, submit an issue. There might be some edge cases that have not been tested yet.

• Gin and router bugs

  • bugs caused by url params and routing should be fixed manually. Due to the way in which the routers and controllers are generated, the generated Gin servers won't be able to run initially.

Not installed locally to avoid any dependencies.

• go-pluralize
• strcase

Versions (tags) have a pattern of x.y.z

• x is incremented on big releases.
• y is incremented when there is a change that breaks the previously generated servers.
• z is incremented when there is a change that doesn't break the previously generated servers.

For example, updating from 0.1.0 to 0.1.1 does not break anything. Going from 0.2.0 to 0.3.0 will break stuff.