I much prefer to serve Go applications through an NGINX reverse proxy.
It deals with a lot of stuff for you (static assets, SSL, logging, etc.) and lets you focus on developing your application rather than re-inventing the wheel.
Would be a good idea to add in a section on configuring that type of setup.
With Caddy[0] around, the only thing that keeps me tied to nginx is its performance and tried-and-tested-ness.
Waiting to see someone do some detailed benchmarks on Caddy before I commit to it for production stuff, because I'm too busy and too lazy to do them myself and I have a while left on my paid TLS certs.
I mention Caddy because it includes LetsEncrypt and HTTP/2 out of the box — and is written in Go.
I am sorry for sounding naive, but I have never used a reverse proxy before, I'll work on it though and add a chapter as soon as possible. It'd be great if you can provide me some pointers :)
Just think of it as a load balancer. Just something that sits in front of your application and gives you the opportunity to determine how to handle things before they get to your application.
Usually things like serving images, css, automatically compressing them, automatically compressing other traffic, domain redirects, ssl, etc. Helps keep your application focused although I realize it can be tempting to just do all that inside of go since it's somewhat good at it.
Not many pointers needed, a simple reverse proxy to your local Go app will provide all of the good, mature stuff that NGINX provides, most noteworthy good, simple plug-and-play logging:
location / {
proxy_pass http://127.0.0.1:8088;
}
This of course proxies everything to your Go app; you'd probably want to let NGINX handle static assets as well.
Another argument in favor of running NGINX in front of a Go webserver is that Golang's web server doesn't do any compression by default. It's possible to add in Go via a middleware but it's very simple to configure in NGINX. Also, NGINX's C implementation of compression should be faster than a pure Go implementation.
> Go doesn't allow us to have functions as a part of structs
I don't know what this means. Functions can be fields in structs.
> These methods can only be called by an instance of the struct.
That's not true. Methods are just regular functions, with some syntactic sugar to make them look like methods from other programming languages. They are not dispatched on the receiver value, but rather based on the type.
You are right, the writing is wrong. I was trying to imply in the C++ class sense where we write functions directly inside a class, in Go, we have to define a function over a struct.
In your example:
you call the method using an instance of T right? that was what I was saying, we have to define methods outside the struct declaration and then call it using an object of struct.
No it doesn't "When something isn't good, you needn't pretend that it is.". I'm not using offensive language like "you are stupid" or similar. It is however a critique comment pointing out that the work is amateurish. Just look at it - text and code are full of false information and bugs. It's obvious it's written by somebody with very little experience.
I am the author of this book, I'd love to get feedback on the book. I haven't updated much in the last few months. But I am always looking to improve the book for newcomers.
Well, as others have pointed out, sqlite is simple and easy to use, that way we can work on the core functions of the app rather than having to worry about the database.
Also, as far as Go language is concerned, we do not really have to worry about the underlying database, the code, as others have rightly pointed out, is totally reusable
That seems a bit overkill. With telling a user how to use mysql/postgres/&c., there will also be questions about setting up these systems, so it seems that "just use sqlite" is a valid path if you're just wanting to go over basic usage.
The code is typically identical/reusable, it's all using the same stdlib database package. The only two lines that would change would be the import (import a mysql or postgres driver instead of sqlite) and the database handle - `db, err := sql.Open("sqlite3", "./newtask.db")` would become something like `db, err := sql.Open("postgres", "user=pqgotest dbname=pqgotest sslmode=verify-full")`. One of the many bright spots of Go.
Huh? Why? Sqlite is closer to postgres/MySQL is you're looking for a reference base and actually sqlite is a pretty awesome database. Bolt DB is much more niche.
Like you describe in the book, I had written a web-app in Go in which I was doing all the SQL handling manually, I found that it became very difficult to maintain this over time as I added new columns and more tables. Just the other day I switched to using GORM (github.com/jinzhu/gorm) for my database drivers and so far it's been a life-saver. Since this is a book about not using frameworks, GORM might be overkill for what you want to do, but I thought it was worth mentioning.
I used to think that using raw SQL is better than using ORMs because I have had a bad experience using django1's OEM. I will look into the ORM now. Thanks for the advice!
Also, I use visual studio code, so haven't really written import statements on my own! I'll use html/template, because no matter who wrote the templates, escaping them is a good idea
FWIW, the reason you're interested in escaping HTML templates is not usually the templates themselves but the user content that gets injected into them.
You may want to mention something about Graceful restarts to avoid downtime when upgrading. A great library to achieve this is: https://github.com/facebookgo/grace
I've been using this, found it through Google awhile back. I didn't want a framework and this helps. I had to search more for Redis and PG and Solr but the front-end stuff here (html,css,js) was helpful
I know, but the thing is I have 0 practical experience in web app development, I work in the data warehousing field. So really have no idea about deployment, the only deployment I do is from the dev version of my to-do app to my own local version which I call Production :d
> Till now we never used any third party library or a framework in this book, this is for the first time that we are doing so, as per the arrogant people on HN we better use libraries for handling sessions, since security is the #1 aspect of any web application,
Stackoverflow is worse in some ways. I'm not sure you (or anyone or Harvard) can ever please HN, so unless that is the goal of your book, why bother?
It deals with a lot of stuff for you (static assets, SSL, logging, etc.) and lets you focus on developing your application rather than re-inventing the wheel.
Would be a good idea to add in a section on configuring that type of setup.