Ask HN: If you were CTO of a new start-up, what would your stack be? | Hacker News Reader

Ask HN: If you were CTO of a new start-up, what would your stack be?

20 pointsacron035 comments

Just an exercise in curiosity. Nothing high-scale, website is your product, ~10,000 users.

Rails, building a versioned API. Try to keep it incredibly light weight with just VERBS applied to resources. Trying to avoid that word that starts with R and ends with ESTful.

I might use RBX or JRuby depending on what kind of and the amount background processing. Basically if I need native threads.

For things that might be heavy and require both speed and massive concurrency I might switch that out to either Go or Erlang.

In fact, for some portion of the APIs I suspect not to use ruby and instead Go/Erland. Depends basically on the situation.

I will probably stick to SQL, PostgreSQL to be precise. For heavy relationships, I'd use Redis for associations. Keeping Model IDS in sets or orderedSets. That way I could just keep my SQL light weight and only need indexing the ids and avoid that whole mess of compound index.

Memcache with Rack-Cache.. I'd suspect I'd rely heavily on HTTP Cache. That way I don't need to cache data objects, and have to redo the json all over again. Basically tring to avoid layers of caches, when I could just do it at the user end point. Of course I understand edge cases will turn up. So I'll be prepared for that.

Then the client(s). iOS, just because I'm pretty certain whatever we offer, we can offer it better on the mobile platform as a native, also I can code OBJ-C & design for iPhone.

Web, I'm probably not going to be doing the web-frontend much so I leave it to whoever I deem fit for the web. Whoever this person is, hen will be in charge of both the design as well as the code base for the web front-end. Meaning whatever stack hen choses to work with.

Preferably Bourbon.io with SASS/SCSS and either Ember.js or Batman.js.

Verbs and resources ARE REST. By definition.

> Verbs and resources ARE REST. By definition.

Verbs and resources without HATEOAS are not REST. By definition.

Proper semantic use of HTTP verbs against HTTP-accessible resource is just an idiomatic HTTP API, not REST.

:) I was just being facetious.

For the whole response or just that part?

Just that part. I feel like people abuse the acronym too much.

I had a company call their api RESTful., it was XML being served in JSON through SOAP.

If I'm looking at ~10,000 users, I will go with Ruby on Rails (ROR) because I have a few years of ROR experience and I can get things done faster. ROR handles many things for you (like security) and there are many gems out there to help you get things done that otherwise would have been complicated (devise for generating users database). When you are done, push it up on heroku and you will have a solid product.

If your site is very real time (chat, real-time data), I'd look into meteor. They are a framework built on top of NodeJS and its built from the ground up to be real time. Like ROR, they do many wonders for you app (security) and has built in user authentication system.

If you are looking to build the site for a learning experience and want to learn how the web works and build everything from the ground up, go with NodeJS. Install packages yourself, tinker around with security, etc. Its a great exercise.

Your stack should be whatever will allow you to test your assumptions the quickest.

For a lot of cases this will be whatever you are most familiar with. There will be some cases where a piece of tech you haven't used before simply offers enough benefits to make it worth climbing the learning curve. However you want to use the best tool for the job, for startups the job isn't to build an amazing, scalable and maintainable code base, or even a great product. It's to find a "repeatable and scalable business model" before you run out of money.

This means speed is of the essence, choose what ever technology you can launch your MVP and test your assumptions with in the shortest possible time. At the same time balancing medium term scalability and maintainability concerns.

Scala with Akka, and RabbitMQ for scaling across multiple servers. This would be a bit more work up front than a web framework like Django but it would be more maintainable in the long run due to the fact that Akka encourages writing simple loosely coupled code that does one thing (Single Responsibility Principle). Even more important is to get the dev team working using TDD (Test First Development) and provide a proper vision to guide them. Things like Uncle Bob's Clean Code book, and the raw, original Agile manifesto before it got sucked into the Scrum and XP methodology machine. Even though the code is more functional than object-oriented, the SOLID principles still mostly apply.

Some alternate choices that could be OK if you can find at least one good developer to lead the team, are Clojure, or Erlang/Elixir. With the Erlang virtual machine, RabbitMQ would not be necessary, although I like it because it gives you a lot of points where you can measure/monitor the internals of your application. I would also seriously look at adding Apache Camel to the mix even though Akka does not require Camel to integrate actors. But Camel is a thin layer that makes it easier to reconfigure integration points.

There is no way to answer this question without knowing more about what that product is.

If that product can be well-served with a customized wordpress template (or similar off-the-shelf CMS), that's probably what you should do.

If that website requires process tons of data in real-time, that pushes you to a different stack.

If that website requires storing and processing tons of data, but processing can be batched, different stack.

If that site is an interactive game, different stack.

Do you need to stream data? video? process large uploads? Should it work offline? Should it work on multiple devices that are offline at the same time and sync up later? Is it mainly mobile? Is it a big enterprise-y application? Mainly consumed by teenagers on mobile phones? Serving a population in rural Brazil / India / Bangladesh?

You could go on like this for quite some time.

I certainly have my preferences, like any dev, but the needs of the project are going to dictate what's needed.

No one like a non answer even though it is the right answer. That being said it is true that many will waste countless hours when a CMS is perfectly viable and could significantly reduce headache.

Sinatra for the API, Redis & PostgreSQL for data, Ember & SCSS on the front-end.

Redis should be able to handle the most common data for 10k users, with PG for the less commonly requested data.

No particular reason for choosing Ember other than I like it better than Angular/Knockout/Backbone, and same for SCSS as opposed to LESS/Stylus.

I feel like Node would be overkill in this scenario, Sinatra is so much faster to develop with (for me personally, I'm sure there are plenty of Noders out there who could swing it with their eyes closed).

PostgreSQL + Redis + Ember + SCSS + Sinatra; I call it "The PRESS Stack"

Honestly? For a large project probably PHP/jQuery/Bootstrap, iOS, MySQL on AWS.

For something smaller and quick I'd try to use Parse.

Front-end: Angular sounds like an awesome thing to bandwagon on to, but I've personally had more exprience with jQuery+KnockoutJS, and that's worked fine for me. But I hear that Angular has way better structure, once you get over the learning curve

Middle: I really like Flask -- essentially django lite, and very very quick to get to writing real code, plugins are pretty good also. BUT, if you want to handle websockets and stuff, you need to get something like tornado/gevent/etc involved... I liked the quickness with which I could work with websockets with NodeJS, but callback hell is no fun. Revel (Go) might be good, if you want to reap some speed benefits.

Database: I would suggest Postgres. Solid as a rock, has new features (9.3 is pretty spiffy). If you're going the non-relational route, I really like RethinkDB -- fantastic management console, really modern functionality (dumping is super easy, etc).

Based on your requirement I would think about 2 options for backend (REST service):

1. if I am a single backend developer for some period of time or have 1-2 people around I would go with what I am most familiar with and what can suit: in my case it is Scala, Playframework, MongoDb or Postgres.

2. If I start with a team to hire and work on the whole stack I would start with something that is both rather hot/new to attract smart developers and keep them motivated and stable, with good stable choice of libraries to focus on the product not fixing issues in half-baked libraries. I believe Node.js MEAN stack or Rails would be my choice.

For front-end I would go with Javascript/Angular.js

I'm old, but just starting the design phase of a new app for my company.

Frontend will be angular and bootstrap as it's working really well for other projects.

On the backend java, spring and jetty will be used. Netty will also be in there as we have non http networking needs as well.

PostgreSQL is our standby database, but we're also evaluating Cassandra and rethinkdb for our non-relational needs.

Why Java? We have in house java knowledge and deployment is much easier than Python, ruby and node.

Nobody proposing very specific technologies here seems to be taking into consideration the cost of the resources who have competence with those technologies, and how easily these resources can be located and recruited.

A good CTO will always look at non-technical considerations of this nature because, in most cases, your ability to deliver is not just about the technologies you select.

We recently had this exercise at our mobile start up when we were deciding on stack. Like any other start-up we wanted to be nimble and fast, so we decided to use ready products with our start up. We chose Parse BaaS for our data, Dotcloud PaaS (PHP, CSS, HTML) for hosting. So the only major things that we needed to worry about involved HTML, Javascript, PHP, Objective-C.

.NET and Node with Azure/Azure Mobile Services and progressively enhanced Backbone on the front-end of the website.

Anything Cognitect - just because I've never met a Relevancer I didn't like.

If I have to start a new project, the initial code and MVP would be rails, just to show off, but since I've been dealing with Erlang, I must say that baby is too sexy to say no. It would be between Earlang or either Go...

Honestly, whatever the best tools for the job are.

My preference? Rails, Ember, Mongo, Haml/Sass

Front-End: I'm used to jQuery + Jade, but possibly something fancier like angular/ember, or even meteor.

Middle: Node.js + Express (unless using meteor). If not node, then Sinatra.

Database: MongoDB, Redis if necessary.

Angular for the front end work. Backend API built out in either Python with a minimal framework like flask or perhaps Go if I had the luxury of time to learn as I built it. Postgres for the DB.

roostrap. A java and Spring based framework that runs beautifully on AppEngine along with Twitter Bootstrap 3 for the UI.

Ticks the following with ease.

[x] UI [x] API/Code generation [x] Scalability [x] Libraries and support [x] Free to host MVP

Project: http://bhagyas.github.io/roostrap Sample/Demo : http://roostrap.appspot.com/

Front-end: Angular, as it is great. Back-end: Rails, its what im familiar with. Db: postgresql Bootstrap 3.0 -This is a great and well designed library. sass

Rails or Django on Heroku, most likely.

The frameworks (try to) help you keep from botching things so bad it's painful later, and heroku just because I hate server config.

Scala/Play for any heavy lifting. Node for the web layer and Angular/SASS for the front end with grunt to handle node and front end builds.

We used plain old Python/Flask with raw SQL, PostgreSQL, and HTML/JS/CSS on our webapp and I would do it again.

Go, MongoDB, AngularJS.

Go for being modern, fast and fun. MongoDB or similar for its scalability and being quite good for modern applications. Plus I'm just tired of SQL DBs.

AngularJS for a rich client experience, plus I look at REST servers as serving any type of client and the thick web client is but one such potential user of the service. Expanding to mobile or god-knows-what is easier.

I have more details about architecture I'd prefer and could write a lot on that, but don't want to.

Pick MongoDB only if you know it well or it exactly fits your use case. Otherwise just use a relational DB since it will suffice, more flexible, more scalable, and higher performance.

Rails, devise, postgres, heroku, scss, backbone.js or angular.js. Stripe, Google Analytics, Xero, Dashing.

AngularJS, SCSS, Python or PHP, Memcache, SQL database (MongoDB where needed).

Flask, Mongo, Redis, Heroku

Django, Nginx, mysql

Reply on news.ycombinator.com