

Go-bootstrap: Generates a lean and mean Go web project - didip
http://go-bootstrap.io/

======
zedpm
Excellent overview. I'm sick to death of landing pages that are vague, hard to
navigate, and leave you wondering what the project is all about; you avoided
all of that. In particular, the "Decisions made for you" clearly answers many
of the questions someone will have when they investigate a project like this.
Kudos.

~~~
rylee
I can't agree enough! More projects need this "decisions made for you" section
in them.

Hmm, maybe I should go through the common Ruby frameworks and add a section
like this in a pull request...

~~~
MetaCosm
Indeed, it is one of the best one page introduction for a project I have ever
seen. Making me go back to some of my projects and redo the READMEs.

------
superuser2
>It does not use ORM nor installs one.

Take a look at [1]. Congratulations, you've written an ORM.

The belief that ORMs are evil is precisely the belief that this sort of code
should be repeated everywhere database access is performed. If you have
generalized routines for interacting with the database with more comfortable
abstractions then string concatenation, you _are_ using an ORM, but possibly a
poorly tested, poorly documented homegrown one instead of a generally accepted
solution that has more eyes on it. You are what you claim to be above.

Which is not bad, lightweight ORM is awesome. You could also debate
terminology that these are not really objects, but the spirit is still pretty
similar to activerecord and sqlalchemy.

[1][https://github.com/go-bootstrap/go-
bootstrap/blob/master/bla...](https://github.com/go-bootstrap/go-
bootstrap/blob/master/blank/dal/base.go)

~~~
civilian
And if you look at dal/README.md [https://github.com/go-bootstrap/go-
bootstrap/tree/master/bla...](https://github.com/go-bootstrap/go-
bootstrap/tree/master/blank/dal) , they say that they got the "data access
layer" defintion from wikipedia
[http://en.wikipedia.org/wiki/Data_access_layer](http://en.wikipedia.org/wiki/Data_access_layer)
, and in the last line of the wiki page says:

> _Object-Relational Mapping tools provide data layers in this fashion,
> following the active record model. The ORM /active-record model is popular
> with web frameworks._

:D

~~~
superuser2
It may be technically true that this DAL is not _really_ on ORM, but saying
that the project skeleton does not contain an ORM is misleading at best. It
would be simplest to just rework the language to something like, "a
lightweight ORM" or "a database access layer like what's found in traditional
ORMs" or something.

------
ejcx
I like the project. You integrated a lot of well known and standard packages
that people writing Go-WebApps would want, and didn't make the project super
heavyweight. Very useful and still very light. I will definitely be using it,
since one of my biggest problems with getting new go machines set up is going
out and finding all the packages I have used in the past.

On top of that, you got me another Gorilla Secure Cookie default integrity key
to add to my project for attacking Gorilla SecureCookies.

~~~
kristianp
This project generates scaffolding code, that key should be generated too.

~~~
didip
Excellent feedback! I've updated the code to randomly generate the key during
bootstrap.

------
sinatra
Would love to see something like this for RESTful Web Services built on Go
with /users, auth, rate-limiting, etc already working out of the box.

~~~
loosescrews
I wrote something like that a while back:
[https://github.com/iangudger/basicGoAPI](https://github.com/iangudger/basicGoAPI)

No rate limiting, but it has pretty much everything else. If you want to add
it I would welcome a pull request :)

~~~
abtinf
Your project is GPL licensed. Is that your idea of a joke?

There is a place for the GPL, but this is not it.

~~~
papaf
I have found the GPL is workable in web projects:

[https://programmers.stackexchange.com/questions/132485/does-...](https://programmers.stackexchange.com/questions/132485/does-
a-website-running-modified-gpl-software-have-an-obligation-to-release-their)

I understand why people don't like the GPL but its not a showstopper for most
business applications.

~~~
abtinf
You are grossly misguided and should consult a lawyer.

Linking to a random programmers stackexchange question is an unwise way to
make licensing decisions.

Per GNU's own faq at [https://www.gnu.org/licenses/gpl-
faq.html#UnreleasedMods](https://www.gnu.org/licenses/gpl-
faq.html#UnreleasedMods):

    
    
      A company is running a modified version of a GPL'ed program on a web site. Does the GPL say they must release their modified sources?
    
      The GPL permits anyone to make a modified version and use it without ever distributing it to others. What this company is doing is a special case of that. Therefore, the company does not have to release the modified sources.
    
      It is essential for people to have the freedom to make modifications and use them privately, without ever publishing those modifications. However, putting the program on a server machine for the public to talk to is hardly “private” use, so it would be legitimate to require release of the source code in that special case. Developers who wish to address this might want to use the GNU Affero GPL for programs designed for network server use.
    
    

In case you missed it: _However, putting the program on a server machine for
the public to talk to is hardly “private” use, so it would be legitimate to
require release of the source code in that special case._

There are numerous other potential consequences to the GPL and the question of
when propagation occurs is ambiguous.

~~~
Vendan
In fact, you are actually the one who is grossly misguided. Per that exact
quote,

    
    
      The GPL permits anyone to make a modified version and use it without ever distributing it to others. What this company is doing is a special case of that. Therefore, the company does not have to release the modified sources.
    
    

Specifically

    
    
      Therefore, the company does not have to release the modified sources.
    

The faq is explicitly stating that the GPL would not require releasing
modified source, and that if you want to force the releasing of modified
sources, you should use the AGPL, as it has a clause to cover network server
software

------
czbond
After fiddling with the initial rev, and having issues - I pulled your May 8
commits and this is very nice and working well! Thank you so much! I've been
using a "book in progress" for better practices for go web programming
([http://www.manning.com/chang/](http://www.manning.com/chang/)). But this was
much better for me to get going! Cheers.

~~~
didip
Glad to hear that the project helps!

------
enneff
I'm a bit confused as to why the initial step is a "git clone". Why not "go
get"?

~~~
didip
Great point! I've updated the instruction.

~~~
enneff
Looking better, but since the 'go get' step compiles your main.go and puts it
in $GOPATH/bin/go-bootstrap, the instructions could be simpler still:

    
    
        go get github.com/go-bootstrap/go-bootstrap
        $GOPATH/bin/go-bootstrap -dir github.com/$GIT_USER/$PROJECT_NAME
        cd $GOPATH/src/github.com/$GIT_USER/$PROJECT_NAME && go run main.go

------
yarper
I wrote a simple one of these for rust using nickel.rs a while ago.

[https://news.ycombinator.com/item?id=9519642](https://news.ycombinator.com/item?id=9519642)

------
captainkrtek
Just got this up and running, this is fantastic! great work

------
shocks
This is really exciting. Thank you very much.

Anyone with a 'large' web project written in Go want to chime in?

~~~
Vendan
IMHO, once you've got a db attached, "secure cookies" are a bad idea.

~~~
Jailbird
without reference to this project -

Perhaps you meant storing all session data is a bad idea versus just an ID?
(If so, I'm with you)

If not - how would you identify an authenticated user? Or, how would you look
up all their relevant session data in the DB?

~~~
Vendan
"securecookies" is a term used, at least in the context of
github.com/gorilla/sessions, to refer to a session storage based on encrypting
all of the session data and sending it as a cookie. That means all of your
session data, including if the user is authenticated and even which user it
is, is sent to the browser and back to the server on the next (and subsequent)
request(s). This is an interesting concept, but IMHO, rather flawed. About the
only valid use is for small micro-apps that don't have any server side
persistent storage.

A db based session, which really wouldn't be that hard to set up with
github.com/gorilla/sessions, would just send a randomly generated session id
to the client in a cookie, save the data in the db, then read that data back
out of the db on the next request.

~~~
elithrar
> That means all of your session data, including if the user is authenticated
> and even which user it is, is sent to the browser and back to the server on
> the next (and subsequent) request(s). This is an interesting concept, but
> IMHO, rather flawed. About the only valid use is for small micro-apps that
> don't have any server side persistent storage.

I'm curious: what do you consider particularly flawed? DB backed sessions with
simple ID-storing cookies suffer many of the same problems, with the primary
issue being that you can MitM the cookie and masquerade as another user if not
served over HTTPS.

DB (SQL, Redis, et. al) backed sessions are nice if you are storing genuine
data (i.e. form data), because cookies typically have a 4KB per domain limit
in most browsers.

If you are just storing a user ID, email address and/or admin flag, the cookie
is authenticated (to prevent modification of those values) and served over
HTTPS (only, ever) then there isn't an immediate problem there. You also don't
have to worry about hitting your DB for each request - Redis is real quick,
but (without hard numbers) I don't expect that sending 1KB of cookie header
data would be slower either.

~~~
Vendan
Keep in mind, your authenticated cookie is exactly as easy to MITM as a ID
storing cookie, and potentially more dangerous. A session can be deleted from
the db, and then that session cookie is dead. An authenticated cookie is good
forever, unless you start putting expiration times or something similar. Issue
with that is now you have to make sure it's all done correctly, and there's no
bugs that may make the cookie good forever/impossible to revoke. Whereas, you
get that kinda stuff for free with a db backed session, just delete the
session and they are logged out, period.

~~~
4ydx
You could always, you know, change the code (which is simple) so that an
"infinite" expiry date is no longer valid. Line 215.

[https://github.com/gorilla/securecookie/blob/master/secureco...](https://github.com/gorilla/securecookie/blob/master/securecookie.go)

As for "impossible to revoke" well if you have control over your server you
can do whatever you like so this falls into the very not-at-all-impossible
category. As a baseline as long as there is no personal information in the
"secure cookie" there really is no issue at all.

~~~
Vendan
So you just removed the ability to have a "Log me in forever" checkbox.

A expiry date system is literally impossible to revoke without somehow
maintaining a list of valid or invalid cookies, and by that point, you are
hitting a database for each cookie.

So, one way, you don't have as much control, and you can't revoke a stolen
cookie with potentially high level access rights. The other way, you are
replicating a db backed session, and heaping complexity on top of it.

~~~
4ydx
If we are dealing with a subset of bad cookies, then I suppose it becomes a
hard question of what-to-do. We could put something into the code to
distinguish and then require a minimum last good date of some sort. It is
messy and I wouldn't want to do that, but really I just want to point out that
your insistence on it being "impossible" just isn't true. If we just let
ourselves revoke everything, then it is much simpler. I wonder how the "known
subset of bad cookies" situation arises. I suppose it could, but you could in
turn release an announcement telling your users that for all of their
protection you are requiring that they login again, insert a minimum required
date and move on with life. There are plenty of ways to deal with the
situation and none of them are impossible.

~~~
Vendan
Really? Could you try actually reading what I've written?

    
    
        impossible to revoke without somehow maintaining a list of valid or invalid cookies
    

Completely true. A minimum date like you are saying is still "some kind of
list of valid or invalid cookies". Or are you going to get into the semantics
of "that's not a list"? As an example of something that you can't do without
tying a database into it, I've seen sites that let you log individual
computers out of the system from your account page. No way to do that without
a valid/not valid check in the DB.

~~~
4ydx
Values are values whether or not they are in a db. It is situation dependant
and probably not (happily) manageable in a large scale application. Saying
things are "impossible" with such a heavy hand is a bit over the top. If my
cookies have a date that is valid, then I can easily keep that bit of nasty
logic in the code. I wouldn't do that personally, but it is doable. Take it
easy :)

------
elcct
You can also check this one
[http://defaultproject.com/](http://defaultproject.com/) Based on Goji and
Mongo.

This site uses it [http://gifuk.com/](http://gifuk.com/)

------
bsaul
great initiative ! thanks a lot !

