Comment by buro9 | Hacker News Reader

Comment by buro9 | Hacker News Reader

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.

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.

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

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.

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.

When talking about API "quality" I mean "does what it says on the tin, reliably".

Testing means you catch regressions.

You seem to be talking about API design, which is honestly a minor concern compared to whether it works reliably.

Have you ever tried to use the Facebook API? It breaks randomly such as endpoints suddenly return 404's, and there is no followup to bug reports.

That is what I'm talking about when I say "quality".

A "perfectly designed" API that randomly breaks because someone made a change and the lack of tests means its an end-user who discovers it is worse than terrible IMO.

- You can have many clients that talk to the same backend. This is really nice if you have an api that you can offer to partners.

- You can throw your client app away and build a new one pretty quickly without worries because it's totally decoupled from the backend. This is really nice when you have fickle stakeholders that have no idea what they want.

If all you're changing is the way it's presented to the user in a browser, you can still make changes without affecting the API - the logic is the same, you just modify the html templates.

Client using API (irrespective of languages used) is about dogfooding. And, actually prevents the "one bug = two updates" scenario you suggest.

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.

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.

Thx Buro9

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

Reply on news.ycombinator.com