Build Your Own Web Framework in Go | Hacker News Reader

Build Your Own Web Framework in Go

nicolasmerouze.com

99 pointstibastral236 comments

A framework calls your code, a library is called by your code.

In the long run, when you start a web application using packages like "net/http" and the gorilla toolkit, sooner or later it becomes framework-like, because you start to group your code together, you refactor it and make it easiliy extendable _for the app you are writing_. So, every app becomes a framework on it's own. And what I like about Go is the fact, that building such mini framworks is easy, and does not take much time - but the most important aspect is, that you don't need a huge framework that does all the things.

>A framework calls your code, a library is called by your code.

Exactly. Very subjective, but I lean towards library with golang, because it seems more natural, and the bigger a framework gets, the more you have to do work for it to get it to do work for you.

> A framework calls your code

That's not a bad thing. Delegation is a very useful composition pattern.

A colleague of mine has often said, "Regardless of whether you choose to use a framework or not, eventually you'll be regretting your decision."

I kind of disagree with this article. With go its so easy to get started with http that most of the time you dont even need a framework. If you do, most good frameworks use the following function as a common basis:

  func(http.ResponseWriter, *http.Request)

I started with barebones http, then used gorilla, and later started using negrioni.

Any new library with uses this function helps me.

So in the end: you dont need a framework, but libraries are nice.

Note: My api is a simple json based rest service.

I created a small starter Go Web Server from a website that I'm building:

GitHub: https://github.com/melling/GoWebServer

I'm not sure that I like embedding html in fmt.Print() methods, along with templates. A lot of my page handlers look something like this:

https://github.com/melling/GoWebServer/blob/master/src/webse...

My site is about 4000-5000 lines of Go, with a bit of "repeating myself". I'd like to hear from devs who've built larger sites.

Btw, here's my site:

http://thespanishsite.com

And the usually "hidden" admin pages where I've done most of my work:

http://thespanishsite.com/admin/summary?language=chinese&pic...

Just looking at your fmt.Print link, you could be wrapping everything requiring a template in functions handling the html/template stuff, i.e. have code specifically interfacing templating for you that you can just pass a command "render this template". I had a lot of problems with working through templating and ended up with my own wrappers around html/template in Djinn(https://github.com/thrisp/djinn).

This dotGo talk[0] about dependencies is spot on. Composition makes you reap all the benefits.

[0]: https://www.youtube.com/watch?v=yi5A3cK1LNA&list=PLMW8Xq7bXr...

That's what this series of articles is doing. It starts with http.Handler and assemble libraries with minimal glue code to make things work without a lot of overhead.

I agree. Those learning path is best for a deep understanding of how go works in the inside.

I think most people that are using core net/http package utilities instead of a framework don't fall under the "deep understanding" category because of the ease and simplicity of said package.

Building a framework is useful for doing that, because you have to understand the routing mechanisms, the way statuses and headers are set within the net/http package, etc.

As someone learning Go and coming from scripting languages this is a great introductory course. I want my APIs to be fast and Go seems to be the best language for that. Finding a middleware solution (negroni) was key for me to feeling productive.

Yes, do make your own framework. And don't leave any documentation either. Hell, invent your own language while you're at it.

It'll make the "should we throw this code out" discussion WAAAAY easier in five years.

I wrote plenty of things nobody but me will ever use, and I'm happy I reinvented lots of wheels along the way. I learned, I had fun, and I still like the results. Not all programming has to take place in a corporate cog-style environment, and not all articles about programming have to justify themselves in that environment, or for sites with millions of visitors. If it's not good for your job, don't use it for your job, and let me do what I want in my free time. If I was a better programmer, I would insert a snarky question about who will program the frameworks of the future if nobody knows how to do anything from "scratch" anymore. I'm just glad we're not that stuck up about HTML and CSS: sure semantic clean things are nice, but nobody would honestly say "god no, don't EVER Write your own CSS, use Bootstrap and tweak the options! It's just too hard, too many things can go wrong." I can see that with crypto, but a "web framework"? Nah. It's more a hello world thing, nothing to freak out over.

Writing a custom framework is cruel to the maintenance programmers down the line. Whoever works the project after you is stuck with a buggy undocumented framework.

Maintenance programmers solely dictating what is cool or allowed is cruel to all programmers everywhere. This is right at the start of my post:

> things nobody but me will ever use

Plus, I imagine I'll rewrite for example my CMS from scratch and/or in a different language every 5-10 years either way, taking a good hard look at what I really ended up needing, and how to best structure it. If I ever used a framework for that, I'd end up forking it and throwing out the 90% things it has which I don't need, cutting out redundant layers of indirection etc., and then what? The next version of the framework comes out, and I do it again? Or I just give up and just take on the bloat? Nah. Not worth it for me.

As I mentioned in my comment above, there's a lot of value in doing this (and in writing your own language) if only for an understanding of how to do such things.

There is of course a huge leap between implementing and formalizing parts of a pre-built net/http package in Go and writing a well-designed language with a quality lexer/parser, but the idea is the same. Assuming you're not doing it to be your standard live environment language/framework of choice, it's a valuable process for learning.

If everyone took the :scoff: "don't write a framework, we already have them" approach it's true we'd have a lot fewer shitty frameworks. But we'd also have a lot fewer good ones.

One of the values in a framework, particularly in Go's case at the moment, is a curated set of libraries and middleware. Since this doesn't exist the cost/effort is high for people looking to enter. It is likely too high for many.

Put it another way, Django and Rails would never have gotten as popular were it not for their 'batteries included' approach. Sure, Sinatra and Flask came, but they came after.

IMV, Go needs a Django/Rails if it is going to be a webframework. If not, if Go is destined for the API layer, it is probably fine with what it has now.

The question is: Should you build a web framework in Go?

In my opinion, Go is great to make REST APIs, but for full-fledged frameworks (with server-generated HTML views) Rails will always be light years ahead for the developer productivity and happiness. That's why the article focus on a web framework to make REST APIs.

That is why Go frameworks need to be made though, the process of evolution will produce varying and improved frameworks. Flotilla(https://github.com/thrisp/flotilla/tree/develop) was started bring something Flask-like to the workflow at Thrisp. Its not rails and intended to be a micro framework, but aims for full-fledged.

And as expected there's no mention of interacting with a database. The lack of a decent orm is the only thing keeping me from using Go for some side projects.

My work is mostly spent in JVM and .NET world and I am not a big fan of Go's design, so I am already biased.

However I am the first voice against ORMs in any project I work on.

If you care about performance, nothing beats tuned prepared stated going through the wire and stored procedures for heavy duty work.

In a few projects we improved batch processing times by a few hours just by throwing the ORM into the garbage can.

ORM works great for basic CRUD stuff like typical web applications. You don't have to use it in every part of your application.

Until you have the whole world banging into your site.

Not a problem that most people will have. If for some reason you do then hopefully you'll be able to monetize that popularity and hire someone who's actually really good it. ORM's are not optimal but they do let you make something quickly if you're not well versed in writing optimized queries, stored procedures, etc. For people like me dropping ORM's seem like a premature optimization.

> If you care about performance, nothing beats tuned prepared stated going through the wire and stored procedures for heavy duty work.

for "heavy duty work",sure.Now write your own hydrators,again,again and again,and let's see how maintainable your code is.

Now the fact is ,it's impossible to write an ORM in Go,without throwing all type safety,just like Java pre-generics,you'd cast and down-cast to Ojbect.

I don't even know what an hydrator is!

A hydrator populates an object from other data.

30 years of experience and never heard that in DB programming.

Thanks for the tip.

I'm the author of the post. I will be addressing this topic soon, but it's a very vast subject, it takes time to write good articles about database interactions and best practices.

Do we need another framework? For learning, sure. But for production, it's better if we contribute to existing framework instead. Relevant XKCD: http://xkcd.com/927/

The original source talks at length about why you shouldn't use the Martini web framework, and links to another post where Jeremy Saenz (Martini's author) more or less disavows his creation (http://blog.codegangsta.io/blog/2014/05/19/my-thoughts-on-ma...). That's an interesting read, I'm surprised that I missed it earlier this year.

I'm also surprised to read that Jeremy has written a more idiomatic successor framework... and named it "Negroni" (http://negroni.codegangsta.io). I don't know if I'm being too hyper-sensitive as a contemporary American, but is this just absolutely cringe-worthy to anyone else? I don't think I could evangelize this at work for that simple reason.

"Oh hey, go check out the 'Negro' framework! It's written by the guy who goes by 'Code Gangsta', and you can read about it on his blog in between YouTube clips of him rapping." (yes, seriously)

Maybe the author enjoys Italian cocktails. It certainly fits considering the 'Martini' name.

What is the sound of one face palming?

I think you're being hyper-sensitive.

I mean it's a common drink.

Reply on news.ycombinator.com