Live data from Hacker News

Ask HN: What Go framework for web API are you using in production?

news.ycombinator.com

31–40 of 65 posts

Re: Ask HN: What Go framework for web API are you using in production?

#31
I've been using the standard library, httptreemux and Chi, depending on how large the project is. I have also used Gorilla in the past, and sometimes use Alice to compose handlers. I prefer to stay close to the standard library, so as to not get stuck with code that depends too heavily on a third library with no easy way to entangle that dependency. I've still got nightmares from late '90s PHP and early 2000 Zope framework disasters... not with a 10 foot pole. Though when your application gets bigger, it makes sense to pull in a good library for some route grouping and helper functions – there are so many options, it's not worth your while to roll your own.

And unless you have very specific requirements, the performance is probably not a relevant concern in a real application either.

Re: Ask HN: What Go framework for web API are you using in production?

#32
post #18

Using no frameworks at all, only https://github.com/julienschmidt/httprouter for routing.

How do you handle database schema migrations?

we use https://github.com/jackc/tern for migrations. It's pretty nice.

Re: Ask HN: What Go framework for web API are you using in production?

#34
post #18

Earlier quoted context omitted.

How do you handle database schema migrations?

I use SQL migrations for this, works fine. Only migrate up, never down, and store the name of migrations already run in the db.

Could you please clarify. Which one of these do you mean (first three results when googling SQL migrations):

(1) https://www.npmjs.com/package/sql-migrations

(2) https://flywaydb.org/documentation/migration/sql

(3) https://github.com/rubenv/sql-migrate

Re: Ask HN: What Go framework for web API are you using in production?

#35
post #18

Earlier quoted context omitted.

How do you handle database schema migrations?

Migrations are a minor pain point for me. The libraries I've used don't support running (all) pending migrations; only those with a timestamp more recent than the previous one. This means we have to finesse the timestamps manually as migrations get merged into the main branch and deployed to various environments. As such, the value offered by the migration library is pretty minimal compared to just remembering to pip…

I take the approach of storing the name of any migrations run in the database in a metadata table - this means you can run them out of order, restore from a backup then run migrations not yet run etc. to test or adjust them. With multiple devs it's often the case that we want to run things out of order on production too, so ordering by time doesn't work and running manually is error-prone.

Code for this here - it'd be pretty simple to put it in its own little tool or even a bash script or something, and there are surely some other tools that do something similar... This one psql only as it relies on the psql binary to load the sql, but hopefully gives you the idea. I haven't bothered developing it further to do things like run a single migration or down migrations as haven't required that so far.

https://github.com/fragmenta/fragmenta/blob/master/migrate.g...

Re: Ask HN: What Go framework for web API are you using in production?

#38

Earlier quoted context omitted.

I use SQL migrations for this, works fine. Only migrate up, never down, and store the name of migrations already run in the db.

Could you please clarify. Which one of these do you mean (first three results when googling SQL migrations): (1) https://www.npmjs.com/package/sql-migrations (2) https://flywaydb.org/documentation/migration/sql (3) https://github.com/rubenv/sql-migrate

None of the above, sorry I didn't mean a tool called 'sql migrations' I meant I simply use sql files (rather than having a special language or config file that translates to sql which is another common approach).

I use something I wrote myself (see link in other comment). Nothing fancy and could be replicated easily - save sql files for migrations, run migration if not in db already, then store in the db the name of the migration run.

Post reply on HN