go-api-frame
Support library for go-api-base so without the go-api-base
library, this code base is worthless.
By combining this library and go-api-base
you can build REST/GRPC go microservice. If you are familiar with RoR scaffolding, well this is the same concept but with go.
Go Versions
Built with Go 1.17+, verified 1.18
Install
get clone github.com/keenfury/go-api-frame
cd go-api-frame
go mod tidy
go install .
This should put it in your $GOPATH/bin
directory, make sure you have that in your $PATH
.
Then you will need to add an env var
to your system, called FRAME_PATH
that points to template
folder within this project.
Usage
See go-api-base cloning your new base code
Once installed, on your command line run this in your new project's root directory
go-api-frame
go-api-frame
will ask a few starter questions:
- correct path to start the project
- which storage devices to create code? (you can choose one or all, if desired)
- If SQL is chosen then which engine?
- If SQL is chosen, do you want to use
GORM
? (if you choose not to use GORM
, go-api-frame
will create sql statements for you, which I prefer, it is all about options)
Once this is completed then a .frame
file is saved in the project's root directory. With this in place then these questions will not be asked again.
The normal flow when starting this cli application within your project's root directory will ask questions to add a new endpoint based on SQL syntax.
How to add your object to the project. The next menu asks this:
- Load File
- Paste Table Syntax
- Prompt for Table Syntax
- Blank Structure
Other than Blank Structure
the options want a sql table syntax, the table name will become the name of the struct and the endpoint's grouping name. For each group/endpoint it will create:
- GET - read by primary key
- GET - list all records
- POST - create new record
- PUT - update full record
- PATCH - update increment
- DELETE - delete by primary key
Boilerplate code
The general setup of boilerplate code follows the convention of Clean Architecture.
Each layer is abstracted from each other by a Go interface. Each layer can easily be tested without knowing who called it and what the downstream layer is. See manager_test.go
for some testing examples since most of the business logic would live in this file (layer).
Both a RESTful and GRPC server code is created for you. See cmd/rest
and cmd/grpc
.
go-api-base
has some hooks that this code base inserts for you, hence why this library and go-api-base
go hand-in-hand.
Notes
If Blank Structure
is chosen, just know most of the boilerplate code will not be include but each file (layer) is created and, at least, should compile. It is up to you then to add the logic for each layer.
If Prompt for Table Syntax
is chosen, after files have been generated a sql structure is created for you and saved in .schema_prompt file will hold this, if you need to copy/paste for generating the table.
I've don't have all sql types represented and they may very from engine to engine on the effectiveness. So this code generation is gives you an as-is end product, but it is go and you can change it how you need/want.
As of this writing, I have written but not tested multi-key functionality, so I can't say it works 100%.
You will be prompted as the end to do go get update && go mod tidy
, make sure you do this. As of this writing, if you specify Postgres as your engine you will need to do a go-generate ./...
to get your mocks working correctly. I think it all comes down that go-api-base has the library reference in it's mod files, Postgres is not and possibly the others as well.