Skip to content

Persistent13/GoTodo

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

8 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Quick and Easy REST API Demo

What is this?

This is a basic REST API to demonstrate an example Go code base authored, by me, Dakota Clark.

It's not intended to be comprehensive or complex but to show that I can productively code in Go as well as with staples such as SQL and caching.

How to use this

Quick start:

Make sure nothing is running on port 8080 and then...

Most *nix and macOS

go run .
# xdg-open for nixins and open for macOS
xdg-open "http://localhost:8080" || open "http://localhost:8080"

Windows, if you're freaky like that. This assumes PowerShell.

go run .
saps "http://localhost:8080"

If you have a client that can handle .http files, feel free to make use of the provided rest-api.http file in the repo after starting the project.

Why no auth?

Auth was skipped as I've like the service to be runnable by anyone who clones and runs it locally without requiring any setup. While I could write up an auth layer, I feel that having HTTP auth wouldn't prove much and JWTs are far more common for APIs like this but building a JWT server for just this would be a misstep as in my experience there's a third-party or org central auth provider that would be used in a real project instead.

If you'd like to know more on how I'd handle this in an API or would like a demonstration, please feel free to ask!

Why no ORM/entity framework?

Keeping it simple. Go's SQL package accessed via Echo's middleware filled this demo use case swimmingly but if you're curious about more, feel free to ask me!

SQL migrations are generated by golang-migrate/migrate and are automatically applied on application start. If anything is messed up with the database, simply delete todos.db and restart the server.

Why no HTTPS?

More simplicity. Browsers trust localhost over HTTP and while it's possible to set up an HTTP cert for localhost (I've done it before), I feel that's overengineering for the purposes of this repo.

Why no tests?

For this being so small, the rest-api.http file holds the tests.

In a larger project, I'd have the route functions call handlers that would be testable within go itself but as this is a smaller demo, I've opted to skip that here.

But if you'd like to know how I've done that in other projects, feel free to ask!

Why echo?

While the stdlib can do what echo does as of 1.22 and later, I chose echo due to the middleware support.

Why SQLite?

If you guessed simplicity, you're right! It's easy to get going and has no dependencies outside the code base so it's an easy pick for this.

Beyond SQLite, my deepest SQL experience is with PostgreSQL, then MS SQL, then MySQL/MariaDB.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors