Figure out a tech stack for this project

[rofreg]

What languages/technologies should we use? Here's one possible proposal, but please feel free to propose alternatives, too.

For a project like this, I'd love to keep things small at the start. I think we can do a great job with just a few core components:

• A database. We have data, so we have to store it somewhere. I've had good success with Amazon RDS + MySQL, but other suggestions are welcome!
• A server-side web application framework. I'm most familiar with Ruby on Rails, so I'd vote for that, but our choice should probably depend on the existing technical expertise of the group.
• A cloud hosting platform. I'd vote for Heroku for ease-of-use, as their free tier is more than enough for most low-traffic projects.

Notably, here are a few things that I think we should leave out in v1.0:

• A front-end JavaScript framework. My gut says this is overkill to start. You can accomplish a lot with static web pages, or with just a sprinkling of jQuery! It may make sense in the long-term if this site grows to be more powerful and complex.
• An API. Again, I believe this is overkill to start, especially if we're not using any front-end framework. It could make sense as a later update, though!

Thoughts? I've used this approach to good success in the past – ripta.info and RIBIT both use this stack, and it's made them easy to maintain and update.

[mimsy]

My main objection to this is that I think we ought to create an API from the start.

A simple RESTful JSON-based API server would be straightforward to integrate into whatever application framework(s) we decide to use: the same API could both serve the back-end of a simple static website, and be easy to adapt into one with a more robust front-end framework and visualizations. It would also be immediately accessible to savvier users who want direct access to the underlying data to use however they wish.

I don't think it's a bad idea to start with a minimal user interface, though. We can improve significantly on the existing lobby trackers without using any Javascript at all.

I am fairly agnostic when it comes to application framework--I made a few projects with RoR in the distant past, so I could work with that. I have more experience with Node and PHP back-ends, but I'd also be happy to work in Python. I do think that if we create an API, we should make use of a framework designed for that purpose, e.g. Hug or Slim.

Heroku is nice, but it might make more sense to use AWS, as we already have an account there which we will be using for other purposes--easier to keep track of servers if they're all located in the same place? I don't have a strong opinion on this, though.

[rofreg]

API: That makes sense! My opinion on this is pretty neutral overall – on my own, I would skip the API layer for v0.1 and just use an ORM directly, but I can see the value in building it from the start too.

Hosting: Good call, AWS/Elastic Beanstalk is the logical thing to try first. I haven't been able to get us access to the Code Island AWS account yet (#7), but hopefully that'll happen soon. I wish AWS was a little more friendly for community projects like this (IAM user management is always bizarrely confusing), but I bet we can make it work 🙂

Also, a minor update on the database: the state's new lobbying database uses MySQL, so if we want to make ongoing data imports easier, it'd probably be easiest to use MySQL for our own DB as well. I don't think we'll be doing anything particularly complicated at the database level, so I think that's probably fine?

[paulopperman]

I second the API up front approach. A feature I'd like to see eventually is bulk access to the data via the api. It might be pretty straightforward or no impact, but just want to put that out there while we're making design choices around the database.

[rofreg]

AWS update: after further investigation (#7), it appears we do not have any existing AWS resources, and that the central CFA group does not offer AWS credit. However, they may offer Heroku credit or Microsoft Azure credit. Could be worth looking into 👍

[dj0nes]

Looking through the introduction thread, it seems like there is a majority of people with python skills, so it might make the most sense to go with a simple python framework. I haven't used hug, but I do like the sound of "Obvious. Clean. Radically simple."

When we have some data, I'll make a proof of concept with hug just to try it out. Would appreciate any other suggestions!

I agree with the api-first approach. I think the exercise of defining endpoints will help the group understand what the project is supposed to accomplish, and save us some rework later.

@rofreg I second your no frontend javascript framework sentiment. A JS framework at this point does feel like overkill, and I think just starting out with some well-organized jQuery (not an oxymoron, I swear!) would help newer developers get involved.