31–40 of 50 posts
One of the goals of Martini is to rally developers to create some more reusable web modules in the form of handlers and middleware. Martini has gotten a great response because it doesn't infringe it's api on your modules/middlewares.
I personally think that this is the way to move forward with web development in Go. Less coupling, pull in the dependencies you need, get stuff done.
I'm curious as to why everyone wants a web-framework in Go. Wasn't it primarily designed for back end service-type-of-stuff? Seems like there's plenty of full-stack and micro-web frameworks out there in what ever language you desire, that are in a more web-dev friendly syntax. I guess I don't picture a company saying, we're going to use GO through-and-through for our dev platform. I picture it more as a "well, we now…
Many other tools are good for web dev too, but having played around with it I'd say in principle Go is well suited to it, if you don't mind the lack of mature frameworks/libraries. I don't see why the syntax gets in the way of it being web friendly, which bit did you think would be a problem? Deployment is far simpler with no libraries/gems/packages - single binary Memory usage is an order of magnitude smaller than l…
What I find interesting about Go[1] and the web application community is that people constantly point to speed as a huge selling point. Speed in the sense of latency and request volume per server. I still feel like for the majority of cases, this type of speed difference is not going to matter. The difference between the Go built in web framework at 190,687[2] (1.3 ms) json responses per second and Flask, a popular P…
I guess it'll be interesting to watch how the frameworks mature and start to approach the Rails/Django or other micro-frameworks...
We've chosen Go for two really significant reasons: a) to reduce attack surface area and b) to enable us to distribute binaries to customers who want an enterprise/firewall install inside their own network.
Speaking about surface area, we've reduced the amount of framework code in stack (rails, gems, etc are all off the table) to zero, and we've reduced the app paths to a few tens of lines of code, in most cases.
Whenever one trades off a framework "to make things more secure" one has to be sceptical, there's a massive scope to introduce SQL injection, XSS and other nasties. In Go, in our case this is fairly limited. So take that reason with a pinch of salt if you aren't building a VERY well defined app with VERY small and skilled team. I don't expect this to scale well.
The second part is also a niche value, whilst it will have some benefits for us running our hosted version of Harrow, it'll have more profound benefits when we can sell binary installations to customers.
Finally, learning how to build applications in an API centric manner, without the crutch that is Rails has been interesting, and has made us all better programmers, we have a more interesting architecture now, and are making better use of our tools (we're leaning heavily on PostgreSQL, triggers, stored procs, LISTEN/NOTIFY etc) and we have a faster system.
On the flip side of things, timing attacks are now really something we have to be mindful of. For instance the login endpoint returns "404 Not Found" regardless of whether it's an incorrect password, or the account doesn't exist. Except, interestingly we're using bcrypt (we're switching to pdbfk2 before the public launch) we need to look up the user before we can hash and verify the password. Meaning we respond in All told the decision to build in Go has made the development of the project slower, but has in my mind at least lead to a better quality of software, with things that don't typically show up in Rails/et al projects (foreign key constraints, triggers in the DB).
Of course all these tools are sharp weapons if handled incorrectly, and testing triggers/functions in the database can be a nightmare from a unit/functional testing point of view.
We've avoided technology proliferation (the entire stack is Go, and PostgreSQL, with worker nodes which rely on LXC). The entire application uses three packages not taken from the Go standard library. (db driver and bcrypt library)
Ohh, and our test suite compiles, and runs (all of it.) in less than three seconds. That hasn't hurt much, either.
From someone who's betting the farm on writing a web application in Go ( https://www.harrow.io/ ). We've chosen Go for two really significant reasons: a) to reduce attack surface area and b) to enable us to distribute binaries to customers who want an enterprise/firewall install inside their own network. Speaking about surface area, we've reduced the amount of framework code in stack (rails, gems, etc are all off the…
Interesting approach to the stack, I'm considering the same for some side projects. I like the exercise in a fully API driven approach. A major advantage is the pure separation of client and server means refactoring/changing languages becomes more straightforward you can also isolate data/logic from presentation more cleanly.
All this talk about HTML templating (html/template, etc) & Go web applications, is missing any discussion of what IMHO is a better way to write Go web apps: 1. Write a backend webservice in Go's net/http + Gorilla 2. Use something like angular JS to interact with those webservices. (From the server's perspective this means static HTML/CSS/JS assets that can again be served by Go, from memory if desired). My first cou…
I've even considered Github pages for the HTML. But probably not for production :)
Earlier quoted context omitted.
For me: • I prefer to find my errors at compile time. Consider the time to find and fix a missing method in a go compile (one 'make' and all the info is still in the developer's brain cache) versus eventually having a user drive the website into that method and having a mystery occur on a duck typed language. (hope you have good stack trace logging on the back end) • I prefer a language that doesn't repeatedly break…
Cool. All valid points. I have a question, do you think builds in Go for a large web app will remain fast? I ask from the experience of working in Java with several minute build/deploy times...
When I make changes, refreshing the browser results in a re-compile which takes less than a second (assuming I have modified several files) on my 2012 Macbook pro.
With Go, unit testing is also blazing fast. My entire test suite (around 30+ tests) takes around 0.2 seconds.
Just for comparision, I used Play 2 (Scala) for a short while before that. Re-compilation would take in the region of 10 seconds. Startup costs are high in the Java/.NET world :(
From someone who's betting the farm on writing a web application in Go ( https://www.harrow.io/ ). We've chosen Go for two really significant reasons: a) to reduce attack surface area and b) to enable us to distribute binaries to customers who want an enterprise/firewall install inside their own network. Speaking about surface area, we've reduced the amount of framework code in stack (rails, gems, etc are all off the…
Just an FYI, noticed two typos on your homepage: "easyily" => "Easily", and "ause" => "use". Interesting approach to the stack, I'm considering the same for some side projects. I like the exercise in a fully API driven approach. A major advantage is the pure separation of client and server means refactoring/changing languages becomes more straightforward you can also isolate data/logic from presentation more cleanly.
Earlier quoted context omitted.
For me: • I prefer to find my errors at compile time. Consider the time to find and fix a missing method in a go compile (one 'make' and all the info is still in the developer's brain cache) versus eventually having a user drive the website into that method and having a mystery occur on a duck typed language. (hope you have good stack trace logging on the back end) • I prefer a language that doesn't repeatedly break…
Cool. All valid points. I have a question, do you think builds in Go for a large web app will remain fast? I ask from the experience of working in Java with several minute build/deploy times...