Porting Flask to Go – Jinja2 to Pongo2 | Hacker News Reader

Porting Flask to Go – Jinja2 to Pongo2

blog.thinkful.me

40 pointseatonphil37 comments

Last 2 years I've been using Go (instead of Python), even for webpages & apis. I'm actually considering going back to Python(for webpages and apis) because dealing with database in Go is really ugly. Currently available orms are nowhere near as useful as sqlAlchemy or django orm :(

i recently starting experimenting with moving from python to go and for fun (for web development) and was surprised at the current available options for ORMs. even established frameworks like Revel seem like they are suggesting using raw sql queries still:

https://revel.github.io/manual/database.html

this is golang's Django i believe ?

i'm using beego orm(can be used without using whole framework)

ill check it out - thanks!

Glad to hear i'm not alone in that case. I actually think someone should blog about this, because i've got the suspicion that the "moving to go is fantastic" feeling we get from blog posts suffers from a survivorship bias.

Check out gorm [0] to ease your database interaction pains; it's worked out nicely for me many times.

[0] https://github.com/jinzhu/gorm

I don't have direct experience, but quoting from this[0] seems to indicate that gorm may still have some issues compared to current standard options in the Ruby or Python ecosystems.

"The ORM we ended up using for e.g. our settlement service, Gorm, is not anywhere near the level of maturity of ActiveRecord, and to get its (valuable!) feature set you have to tolerate a) throwing out most of the benefits of using a type-safe language and b) programming bugs which can cause statements which certainly look like they should generate SQL queries to just silently not generate SQL queries. In general, working with the database has been so painful in Go that I have been instead either a) hitting a REST endpoint on an internal API to have Rails do the DB access then return formatted JSON (which Go can actually consume fairly decently) or b) throwing the data at NSQ."

[0] http://www.kalzumeus.com/2015/08/20/designing-and-building-s...

Of course, maturity takes time.

Go is still much newer than Python and Ruby. There's no getting around this fact.

I've come to think the limitations of Go orms are not due to the lack of maturity, but to inherent limitations of the language that are officialy not going to be removed anytime soon ( because they are seen as a feature by the authors).

Something like linq for example seems simply impossible to code in go.

I'm sure that relying on blogs for being informed on matters like this is another kind of bias.

ORMs?

Am I alone when I say that I still hand code SQL into my applications?

Regardless of what web framework I'm using (e.g. Pylons/Rails/Django/etc), I still hand code SQL statement in my applications.

I've had far to many times ORMs unexpectedly nuke performance and have other issues than what's it's worth gaining by using an ORM.

writing raw queries for crud seems like too much effort, especially when performance is not important

By "hand code SQL" I hope you really mean using prepared statements of whatever language/framework you're using, not concatenating strings with input values. If not, say hello to SQLi.

and no authentication/authorization library.

that's not a real problem. only a few frameworks having a good one. In java i handwritten mine.

And golang has the same good crypto tools as Java.

> https://godoc.org/golang.org/x/crypto/pbkdf2

> https://golang.org/pkg/crypto/subtle/

And finally a Token Library: https://github.com/dgrijalva/jwt-go or https://github.com/dvsekhvalnov/jose2go

And that's all you need to write a Authentication / Authorization Library in 100-200 lines of code. And it will mostly be more secure than most of the things you see in the open world.

I have always been scared of implementing my own and put it in production, but you motivate me to do so ;)

CoreOS has released one: https://github.com/coreos/go-oidc

We're currently using it in our own OAuth/OIDC identity provider.

Out of curiosity, what did you most miss from those orms?

handling m2m is especially painful. I just hate writing same long code for fetching old members, checking if members are changed and then updating/inserting new members. Joins are also problematic (i like how beego orm is handling it, but it works only for single object and not multiple objects)

Word! Flask and the flask-sqlalchemy extension are a dreamteam that i wouldn't want to miss anymore. Golang might perform 10x better, but i'd choose the faster development cycle and comfort of Flask at any given day.

I'm missing them more and more. Faster development cycle > performance for most apps.

It might be the problems I solve, or the way I think about them, but I think it's about 50/50 whether the ORM is helpful or in the way. Very often I just want the ORM to go away because I know what I'm doing and the ORM doesn't

I do like sqlx, it seems to hit a balance that works for me. I get to write the SQL and structs come out.

I used sqlx for a while and it's definitely an improvement over std sql, but still isn't full orm.

sqlx (https://github.com/jmoiron/sqlx) is my go-to as well. mgutz/dat (https://github.com/mgutz/dat) and dbr (https://github.com/gocraft/dbr) are also more ORM-like alternatives if that's what you need—query builders with the option to use raw SQL for more complex queries. I also lean on purse (https://github.com/smotes/purse) for keeping my SQL in separate files, but I'd love to see something like Clojure's yesql.

I think the likelihood of seeing an ActiveRecord-style ORM in Go is slim: ActiveRecord is a core part of Rails and can therefore make a lot of safe assumptions about its environment. Any ORM for Go can't do that to the same extent, and big Rails-style frameworks don't gain much of a following in Go.

Have you considered Elixir? I'm a mostly Python guy that was intrigued by Go for web but am now exploring Elixir.

I'm currently in a phase of life when i don't want to reinvent wheel and just focus on building stuff using tools i know (go || python).

same reason i gave up on the idea of using ocaml for crud apps, even though i love it for most other applications. it's really annoying to have to manually manipulate database rows via raw lists of strings :(

Since I gave up SQL databases by using NoSQL ones, ORM is not needed any more.

You know, I always feel ORM is a fix to SQL.

String-based templating is a bad pattern fraught with security issues that shouldn't be translated from old languages to new ones.

I'm interested to hear an alternative, particularly one that will work with separate front end dev teams etc.

The frontend consuming a RESTful API is a viable alternative

That is not really the same as server rendered templates.

Enlive and related libraries for Clojure, Lift for Scala, and heist for Haskell use node transformation. I know that there are a few others I'm forgetting. Basically given a fragment of an HTML 5 or XML document, your view functions transform it into a different fragment. E.g. in Lift, given

    <div class="greeting-container" data-lift="SayHello"><span class="greeting">lorem ipsum</span></div>

And a transformation:

    ".greeting *" #> "Hello World"

The output will be:

     <div class="greeting-container"><span class="greeting">Hello World</span></div>

See http://exploring.liftweb.net/master/index-5.html#entry-CSS-T... et alia

With this technique, your designers can create pure HTML and assets, with no logic in the templates. Basically they create static mock-ups and then the developers "enliven" them.

I prefer this but I don't imagine it will ever become mainstream.

React's JSX is also (as far as I can tell) node based, but with a lot less power (you can really only do insert operations, and the operations don't really compose well).

I recently did a project using this type of template system and it was ok, but not really better than string-based templating. You're really still doing String-based templating except you're embedding all your directives in data attributes and it gets super messy and unreadable.

You need to use something that represents the HTML tree using real data types. I do a lot of my work in Scheme, where we have SXML:

    '(p "hello" (strong "jamespo"))

Before you say "ahhh the parens!", there are special readers such as Racket's Pollen that provide a less Lispy, but still powerful, language for writing documents.

For JavaScript, there's of course a bunch of options such as Mithril:

    m("p", ["hello", m("strong", "jamespo")]);

I don't write Go so I don't know what the options are there. Just trying to raise awareness for safer programming.

For much more in-depth information about the problem, see: http://www.more-magic.net/posts/structurally-fixing-injectio...

Oh thank god. Go is bearable in most areas, but the template system makes me weep. Is there any particular reason the string concatenation doesn't work? Seems special enough to be specialcased ;)

You can use {{print .foo.bar "string"}} and {{printf "%sstring" .foo.bar}} to concat strings in golang template, or even simpler way: {{.foo.bar}}{{"string"}}.

Reply on news.ycombinator.com