Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go-bootstrap: Generates a lean and mean Go web project

go-bootstrap.io

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Go-bootstrap: Generates a lean and mean Go web project

#41

Post by burntsushi »

superuser2 wrote: post #27

>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, poo…

I don't really see any object-relational mapping there. I see a set of helper functions for writing basic insert/delete/update queries. Calling that an ORM (even a minimal one) is a bit of a stretch.

Re: Go-bootstrap: Generates a lean and mean Go web project

#42

Post by elithrar »

Vendan wrote: post #21
Jailbird wrote: post #19

Earlier quoted context omitted.

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?

"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…

> 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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#43

Post by elithrar »

danneu wrote: post #37
Vendan wrote: post #21

Earlier quoted context omitted.

"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…

Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.

> Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.

You should authenticate it anyway, to prevent someone from trying to brute force ID generation (and therefore masquerading as another user). Otherwise all hope rides on you using a sufficiently long (CSPRNG-sourced) ID. Authenticating it is good practice.

Re: Go-bootstrap: Generates a lean and mean Go web project

#44

Post by jmoiron »

superuser2 wrote: post #27

>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, poo…

> 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

This is incorrect.

The sqlx library, included in OP, has generalized routines for interacting with the database, but is not an ORM. The squirrel[1] library for Go lets you produce queries without "string concatenation", but is also very much not an ORM.

An ORM is a specific style of library that attempts to map object oriented data patterns to relational concepts. That's why it's called an Object-Relational Mapping. There are good reasons[2] why people find this approach problematic, which aren't down to cargo culting them as "evil" or believing that everyone should repeat data access code in all projects.

[1]http://github.com/lann/squirrel [2]http://en.wikipedia.org/wiki/Object-relational_impedance_mis...

Re: Go-bootstrap: Generates a lean and mean Go web project

#45

Post by Vendan »

elithrar wrote: post #43
danneu wrote: post #37

Earlier quoted context omitted.

Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id.

> Also, you don't need to sign or encrypt the cookie if it's just a securely random session_id. You should authenticate it anyway, to prevent someone from trying to brute force ID generation (and therefore masquerading as another user). Otherwise all hope rides on you using a sufficiently long (CSPRNG-sourced) ID. Authenticating it is good practice.

Authentication really doesn't do anything that extending your id key by that number of bits wouldn't do, i.e. a 32 byte random ID is just as hard to collide as a 16 byte random ID and a 16 byte signature. Technically, if there are any weaknesses in your signature, they may end up making your ID+signature easier to collide. Just going with a pure random ID means 1 less key that you have to keep out of source control.

Re: Go-bootstrap: Generates a lean and mean Go web project

#46

Post by czbond »

danneu wrote: post #36
xienze wrote: post #24

Earlier quoted context omitted.

Rate limiting isn't something your app should be concerned about. That should be handled a layer up, e.g. nginx. Chances are it does a much better job than whatever you could come up with.

Maybe if it's trivial blanket rate-limiting on a single server. Anything more complicated that needs synchronization/database access, I'd rather just read and maintain application-level middleware. It's not rocket science.

Look at Tyk for this, it should be handled at a layer higher than any individual API IMHO.

Re: Go-bootstrap: Generates a lean and mean Go web project

#47

Post by Vendan »

elithrar wrote: post #42
Vendan wrote: post #21

Earlier quoted context omitted.

"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…

> 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 sessi…

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.

Re: Go-bootstrap: Generates a lean and mean Go web project

#48

Post by superuser2 »

jmoiron wrote: post #44
superuser2 wrote: post #27

>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, poo…

> 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 This is incorrect. The sqlx library, included in OP, has generalized routines for interacting with the database, but is not an ORM.…

The simple/typical use case of Django's ORM, sqlalchemy, Rails ActiveRecord, etc. is not much more than a native API for composing SQL queries, and the automated mapping of table rows from the RDBMS into native data structures in the application (which happen to be objects because of the language).

When you claim that you are not using an ORM, a reasonable person would take it to mean that you are forgoing the use of query builders and automated mapping from SQL results to application data structures.

So, it may be true that classifying these libraries as ORMs is incorrect, but the "user experience" as a developer between these libraries and typical ORMs appears to be pretty much the same. Or is that unfair?

Re: Go-bootstrap: Generates a lean and mean Go web project

#49

Post by jmoiron »

superuser2 wrote: post #48
jmoiron wrote: post #44

Earlier quoted context omitted.

> 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 This is incorrect. The sqlx library, included in OP, has generalized routines for interacting with the database, but is not an ORM.…

The simple/typical use case of Django's ORM, sqlalchemy, Rails ActiveRecord, etc. is not much more than a native API for composing SQL queries, and the automated mapping of table rows from the RDBMS into native data structures in the application (which happen to be objects because of the language). When you claim that you are not using an ORM, a reasonable person would take it to mean that you are forgoing the use of…

I have a lot of experience with Django's ORM and I would say that the essential character of these heavier ORMs is missing from the afore mentioned libraries. They can be used in the way you describe, but that's not their typical usage.

AR/Django encourage you to describe your entire schema, _including_ the relationships between tables, as attributes on your model objects. Upon doing this, you get simple and reliable programmatic access to some basic access and storage patterns.

Using this knowledge of your data model, the ORM can now provide you with more advanced tools: it can automatically join across tables (`select_related`), lazily load dependent data[1], generate SQL schema for you, transparently cache queries[2], automatically provide HTML form validators, and even automate database schema migration for you. The more completely you model the system, the more it can do for you.

In these systems, the database is subservient to the model. This is a problem, because the database is reality and the model is a model.

Dropping to "opaque SQL strings" is discouraged, both because it's considered error prone ("You should leave SQL to the professionals! There are lots of eyes on this!") and because there is often no graceful way to integrate custom query code with your model layer; instead, you investigate how to do so within the confines of the ORM. For every case where you can eventually find what you need (`select_related("user__friends__email")`), there are a dozen where you can't.

People start writing things in application code that could be handled easily and more efficiently by the database: aggregations are a classic, since ORMs support is either missing or incredibly complex. As soon as the application becomes non-trivial[3], the problems magnify. They don't do this because they are stupid, or bad developers, they do this because it's what the tools encourage: they encourage simplistic CRUD access and mistrust/suspicion/fear of SQL.

SQLAlchemy is quite different from this, because its primary focus is to model databases, not to provide some kind of declarative object language with its own set of semantics that do not exist in SQL.

Because Go can't do things like meta classes or creating/modifying types at runtime, a lot of this simply isn't there, even though people want it.

Sqlx does like 2 things; it adds named query parameter support, and it marshals rows into structs. Squirrel is just a query builder. The whole philosophy that the database must somehow be modeled and that access to the database is done via that model is absent.

[1] This is especially durable tarmac with which to pave your road to hell.

[2] http://github.com/jmoiron/johnny-cache

[3] This can mean "lots of requests", or "complex schema", or "complex reporting requirements"... all sorts of things.

Re: Go-bootstrap: Generates a lean and mean Go web project

#50

Post by 4ydx »

Vendan wrote: post #47
elithrar wrote: post #42

Earlier quoted context omitted.

> 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 sessi…

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 g…

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...

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.

Post reply on HN