4 ms·

I write Go for a living, and know Ruby/Rails, Python/Django, Node, PHP and C# amongst others. I don't think one thing wins everything. I'd shoot for: 1. Post

by buro9 9y ago

I write Go for a living, and know Ruby/Rails, Python/Django, Node, PHP and C# amongst others. I don't think one thing wins everything. I'd shoot for: 1. PostgreSQL for DB 2. Admin tool in Django 3. API in Go 4. Front-end in whatever you know best. Go I find best for APIs. But there's no out of the box admin tooling and the web stuff still feels immature (l10n and i18n). Django admin has always proven solid, but maintaining APIs in Python over many years has been more overhead than Go APIs. I liked the web stuff, but kept finding I ended up using third party extras that didn't seem as well maintained. PostgreSQL for the database is a no-brainer and allows easy migration to Google Cloud or whatever when you're ready. The front-end is personal choice... whatever you can be most productive in and it handles all of the internationalisation stuff. Not a great help I know... it feels like there are fewer one-stop shops really capable of shining at every level. C# should be a contender, it's tooling is great at all levels, but I don't know of a web framework that brings it all together to make it a few clicks and you're done.

drudru11 9y ago
This is a great help given your experience. Can you elaborate further on why you think Go is best for API work? I do like that go has goroutines, a fast compiler, and a single statically linked binary.
- buro9 9y ago
  Fewer abstractions really help with APIs. Go gets out of the way more, and for APIs that really makes a difference. An example might be handling the Accept header to give back multiple formats... many frameworks try and hide this from you, and so you have to fight to get something done. But Go exposes everything in a consistent and intuitive way, and there are mature packages for all of this stuff so it becomes trivially easy to work with. JSON work is simple, CSV work is simple, XML work is fairly easy, image work is simple. It's pretty beautiful as language/std package experiences go. It would need a more intuitive templating workflow for web stuff though (the "page.html inherits base.html and includes []block_*.html" story is a bit janky), and I've not yet found a decent answer for the l10n and i18n stuff, and whilst Hugo has a great template funcs library they've purposefully entangled it with their code, and so there is a lack of a core template func package to deliver a lot of things along the lines of Django templates. So Go is great for APIs, but weak for web.
  - drudru11 9y ago
    Thx Buro9
stephenr 9y ago
So you end up maintaining two codebases that talk to the backend database? Implement a feature in one, you have to port it to the other too? Sounds like a way to artificially pad hours on a project to me. This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.
- buro9 9y ago
  > This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view. It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API. By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things. So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.
  - stephenr 9y ago
    Any argument about "quality" which only works if the project has no tests, is moot. And two code bases sounds like a reason for more shortcuts to be taken not less to me.
    - octalmage 9y ago
      Tests have nothing to do with it. You can have 100% coverage on your API and it can still not be "quality". The best APIs I've seen have been "API First" design.
jklein11 9y ago
Do you deal with user management with Django? How do you deal with authorization with Go?

by buro9 9y ago

drudru11 9y ago

This is a great help given your experience. Can you elaborate further on why you think Go is best for API work? I do like that go has goroutines, a fast compiler, and a single statically linked binary.

buro9 9y ago
Fewer abstractions really help with APIs. Go gets out of the way more, and for APIs that really makes a difference. An example might be handling the Accept header to give back multiple formats... many frameworks try and hide this from you, and so you have to fight to get something done. But Go exposes everything in a consistent and intuitive way, and there are mature packages for all of this stuff so it becomes trivially easy to work with. JSON work is simple, CSV work is simple, XML work is fairly easy, image work is simple. It's pretty beautiful as language/std package experiences go. It would need a more intuitive templating workflow for web stuff though (the "page.html inherits base.html and includes []block_*.html" story is a bit janky), and I've not yet found a decent answer for the l10n and i18n stuff, and whilst Hugo has a great template funcs library they've purposefully entangled it with their code, and so there is a lack of a core template func package to deliver a lot of things along the lines of Django templates. So Go is great for APIs, but weak for web.
- drudru11 9y ago
  Thx Buro9

stephenr 9y ago

So you end up maintaining two codebases that talk to the backend database? Implement a feature in one, you have to port it to the other too? Sounds like a way to artificially pad hours on a project to me. This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view.

buro9 9y ago
> This obsession people have with "our web app talks to our api" never made sense to me - why are they separate code in the first place? 99% of the difference between a web browser request/response and a web api request/response is down to data serialisation and the view. It stems from APIs having bugs, and not being consumed by the writers. The flows were badly designed because they would never write a client against the API. By making the web be a client to the API, the design, quality and maintenance of the API is very much to the fore. It also allows the implementations to evolve at their own speed, which helps a lot with maintenance, especially when one adds a mobile client, or changes some other UX flow... it becomes easier to work through things. So yes, I agree... slower to get started and 2 codebases. But, so many advantages, higher quality, and lower maintenance costs that arise from the kind of short cuts that a single monolith codebase makes possible.
- stephenr 9y ago
  Any argument about "quality" which only works if the project has no tests, is moot. And two code bases sounds like a reason for more shortcuts to be taken not less to me.
  - octalmage 9y ago
    Tests have nothing to do with it. You can have 100% coverage on your API and it can still not be "quality". The best APIs I've seen have been "API First" design.

jklein11 9y ago

Do you deal with user management with Django? How do you deal with authorization with Go?