carrot / burrow Goto Github PK

throughout building this out - if we find ourselves having multiple administrative CLI tasks, in addition to originator we may want to explore a common task runner to unify things and keep cognitive overhead low.

https://github.com/go-godo/godo seems to be a strong candidate, but open to other suggestions

Currently it's documented as ErrorDetail in the README, where as it should be AddErrorDetail

./go-base-api [production | development | staging | test]

Inside of main load .env.[environment]

.env.test always loads for tests (document it)

Also add:

package environment

type{
    PRODUCTION,
    TEST,
    SOMETINGELSE,
}

Environment env.Get()

env.IsProduction() bool {
    env.Get() == env.PRODUCTION
}

https://github.com/rcrowley/go-metrics seems to be the state of the art

We didn't touch endpoints like:

[GET] /people/{id}/pets
[POST] /people/{id}/pets
[DELETE] /people/{id}/pets

We should come up with a strategy to name these controller methods

in sharing the 12factor doc regarding an implementation question earlier - I realized it might be a good meta-issue to create.

http://12factor.net/

• 1. Codebase - we're on top of this one
• 2. Dependencies - gom is the solution
• 3. Config - store configuration in the environment
• 4. Backing Services - Treat backing services as attached resources
• 5. Build, release, run - Strictly separate build and run stages
• 6. Process - Execute the app as one or more stateless processes
• 7. Port Binding - Export services via port binding
• 8. Concurrency - Scale out via the process model
• 9. Disposability - Maximize robustness with fast startup and graceful shutdown
• 10. Dev/Prod Parity - Keep development, staging, and production as similar as possible
• 11. Logs - Treat logs as event streams
• 12. Admin Processes - Run admin/management tasks as one-off processes

Looks like we've got a few dependencies, we should either add a dependency manager, or list out our dependencies.

Just to make this easy for developers who aren't familiar with Go, we should write a getting started section.

After we added a custom http error handler we forgot to log the errors, which is super valuable during debugging.

Just have to add fmt.Println(err) in the custom http error handler.

Describe where to find them, how to set them up etc

https://github.com/BrandonRomano/serf

The long term goal of this would be to build out a Burrow CLI, but a make file should be sufficient for now

Okay, so we are using some custom recover middleware, which makes me want to bring up the question of whether our default HTTP response code of 500 on the response is even needed.

If we switched this to a 200 and there was an error, wouldn't our middleware catch it and turn it into a 500?

I think this would save us a line in every request at the end from having to set it to 200 (which I find myself sometimes forgetting to do).

Looks like this project assumes you have a local Redis server setup?

Should Redis even be the datastore in this default setup? I'm pretty sure Redis isn't intended to be a primary datastore, so I can't even imagine a use case where we are only using Redis.

Big refactor on develop requires a bunch of changes to the README

we should have a default deployment strategy.

https://github.com/Sirupsen/logrus

cc @tmilewski @BrandonRomano