Backend Tech Stack Choices

[mattrw89]

What do we want to use?

Primary language

• [ ] Go
• [ ] Scala (Possibly with the Play! framework)
• [ ] NodeJS
• [ ] Ruby/Rails
• [ ] Python
• Others?

  Database technology (May need to check a couple here depending on needs)

• [ ] PostgreSQL
• [ ] Riak
• [ ] MongoDB
• [ ] ElasticSearch
• [ ] Redis
• Others?

  Work Queues/Notification

• [ ] AWS SQS + backend processing
• [ ] AWS SES (E-mail)
• [ ] AWS SNS (mobile push notifications, SMS)
• Some other notification provider?

[TJkrusinski]

I'm in for Go on the primary language. Feel like it should properly throw us for a loop in a good way. Would love to do an SQL database since I don't work with SQL ever in my daily workflow, but up for whatever.

Thoughts on Go for the primary language?

[mattrw89]

I'm for Go.

Regarding SQL, if we're going to use it then let's use PostgreSQL. It's a big step up from MySQL. I think an RDBMS will work very well for this app.

Let's look for some frameworks and libraries that we may need to use.

I'm thinking we'll need:

• Router
• HTTP library (I know there is a built-in one but is there another that has an even better API?)
• Some kind of presenter library. A way to create JSON views without doing it totally manually.
• Postgresql bindings. Possibly an ORM/query builder? I may actually prefer building directly on top of the Postgresql bindings. We could create our own core models. Postgresql has a lot of advanced features that most ORMs don't handle. For example, you can increment an integer fully in the DB, meaning that you never have write contention because of native table locking.
• AWS libraries - SES, SNS

[mattrw89]

This looks like a nice fluent SQL preparer w/o all of the ORM overhead.

https://github.com/lann/squirrel

The native pq drivers are here: https://github.com/lib/pq

An absolutely ridiculous list of Go projects: https://code.google.com/p/go-wiki/wiki/Projects

[mattrw89]

Middleware library: https://github.com/codegangsta/negroni/blob/master/README.md

Router: http://www.gorillatoolkit.org/pkg/mux

Context for requests: http://www.gorillatoolkit.org/pkg/context

[TJkrusinski]

I've heard good things about the martini http library, perhaps it's worth a look as well.

[mattrw89]

I'm totally willing to evaluate a more framework-like library such as martini. I'm also very intrigued by bundling our own middleware, router, context, etc so that we can have a fully-optimized and fully-understood methodology end-to-end.

[mattrw89]

By the way, the critique the writer of Martini is speaking of in his blog listed below is what I had read about it (that it was a little bit too magic).

http://blog.codegangsta.io/blog/2014/05/19/my-thoughts-on-martini/

You'll also see on his blog that he factored out the middleware engine into negroni (see above link).

I think we could make what we need with just negroni, mux, context, and a few other packages. The middleware interfaces are so simple that it's not hard to plug in other interfaces. I'll bet a bunch of the Martini-contrib packages would even work with negroni.

[TJkrusinski]

Ah, good point on not using a huge framework I do like of like the idea of doing it bare bones to get the experience. I think it'd be cool to start this way and then if we are in the weeds for too long switch to martini or something of the like.

[mattrw89]

I'm sure we can figure it all out. I'm not too worried about it. I've implemented most of the components in one language or another.