Full Stack Web Developers: What is your "stack"?

Show us your stack here :)

100+ ANSWERS
Dariya Lopukhina
Dariya Lopukhina, Our team has 15 years experience in custom web development.
Written Oct 28, 2015
Back-end:
Ruby on Rails, Java, Scala.
Databases: PostgreSQL, MySQL, MongoDB, Apache Solr, Elasticsearch.
Servers: Apache, Tomcat, Nginx, Jenkins.
Cloud platforms: Engine Yard, Heroku, Amazon EC2, Digital Ocean, Linode.
Payment Systems: 3D Secure, PayPal, Authorize, Stripe, Braintree, eWay, 2CO, Recurly
, etc.

Front-end:
Web: HTML5, CSS3, SASS, LESS, Bootstrap, JavaScript, CoffeeScript, jQuery, Backbone.js,
React.js, Angular.js, Knockout.js, Underscore.js, Lodash.
Mobile: Android, iOS.

Testing:
RSpec,
Cucumber,
Selenium,
Calabash,
Capybara,
SitePrism,
Selenide.
17.3k Views · View Upvotes
Share
MORE ANSWERS BELOW. RELATED QUESTIONS
What is the pay scale for full stack web developer without a degree?
4,575 Views
Full stack web developer : whats your take on it ?
323 Views
What's the difference between web developer, web programmer, and full stack web developer (or
programmer)?
2,050 Views
What are some great full stack web developer tutorials?
687 Views
Is Codeacademy's pro course of full stack Web development worth buying?
217 Views
What are the rules or best rules to learn full stack web development?
2,596 Views
What should be the salary of Full Stack Web Developer using LAMP Stack (3 yrs exp) in India?
1,944 Views
Am I a full stack developer?
4,977 Views
What is the role of a full stack web developer?
915 Views
What is "stack",in full stack developer?
313 Views
Can a 10-12 week coding bootcamp turn you into a full stack web developer?
3,406 Views
Why Angular.js isn't included in the full stack web development course by freeCodeCamp?
224 Views
Is a web full stack developer rare and paid more?
2,879 Views
What path would you suggest I take when wanting to learn Full Stack web development?
213 Views
What should I do after learning full stack web development?
710 Views
OTHER ANSWERS
Renato Santos de Souza
Renato Santos de Souza, Working with web and backend since 2008. Mostly working in data
cleansing tools.
Updated Oct 28, 2015
Backend:

Languages: perl 5.20/5.22, bash, sql

Modules (all from CPAN):
- Moose for OO
- Catalyst for API
- DBIx::Class as very good ORM (DBIx::Class::ResultSet - Represents a query used for fetching
a set of results. - metacpan.org is pure ♥)
- App::ForkProve for testing every little thing as fast as possible
- Daemon::Control + Parallel::Prefork::SpareWorkers for daemonizing scripts
- Yaadgom + http://daux.io for writing API references from tests scripts
- Imager for processing images
- starman

Databases:
- Postgresql 9.4
- S3 (very good to deal as K=>V for super important data)

Backup
- rdiff-backup for offsite,
- S3 for database dumps

Cache and 'chaos control [queue]':

- Redis, nginx

Hosting:
Pretty different here: Datashack and Server4you, small projects starts on AWS until reach
t2.medium, then it's time to migrate!

Tools:
- ffmpeg for processing video.
- Sqitch by theory for database management
- sublime text 2, vim
- ubuntu 14.04
- start-stop-daemon for daemons
- nginx
- docker in some parts #WIP
- jenkins for git pulling / testing / TV dashboard

Tasks Management:
After trying asana, trello, Jira.. we are good on basecamp.

Frontend (pretty bad here):

Old projects => Catalyst + Template TT (slow as hell) + Libcurl.. Only CSS minified our server,
served by cloudflare except by websockets subdomains
New projects => Coming with AngularJS hosted at S3 and calling API directly.

Monitoring Solution:
- http://bloonix.org (hosted by ourselves at linode, much cheap and easier)
- nmon, iptrack, iotop

Security: ufw, fail2ban, port knowing, autossh for tunnels (miss AWS VPC in this topic!)

Things I try to follow:

- kill where possible, no nicer restarts, so your app stay robust against those fatalities.
- never update except for marking row as old
- making backward compatibility as close as possible to 100% (never good to broke an Android
App)
- Make things simple: rare the case when I have and endpoint like
/user/$id/group/$id/comment/$id/upvote. Make it simple: /comment/$id/upvote?user_id=$id and
now you can upvote for group_id, team_id, whatever_happend_id.

--
Were I want to improve:
Using BDR PostgreSQL (multi-master) for some parts
Put everything on docker and run from kubernetes
Creating better HATEOAS APIs. Currently our frontend apps need much intelligence for
working.

-- (open for suggestions for improving any of those areas)

10.7k Views · View Upvotes
Share
Sean Grogg
Sean Grogg, User Experience Engineer, Synergis, at Google
Updated Jun 17
As of June 16th, 2016

Between switching contracts from Intel to Google and researching new architectures on AWS a
lot of my personal development has become much more minimalistic than before and I now
heavily focus on bringing in tools when they’re necessary rather than selecting them at the outset
of a project.

Front

HTML (native, may involve JSX if I use React)

CSS (native, React inline-styles, Bootstrap, some Material Design library)
JavaScript (native with custom micro-library*, may use React)
(*) I have a personal JavaScript library that contains convenience functions found in other
libraries (jQuery, lodash) with very simple, lightweight implementations that fit my programming
style of using JavaScript’s native higher-order functions.

Back

When I manage my own servers (such as EC2):

EC2: Node.js, Express, Sequelize, JWT

EC2/RDS: PostgreSQL
When I utilize “Serverless Architecture” * :

API Gateway: provide Express-like interface to Lambda

Lambda: Node.js, JWT
DynamoDB: well… itself
(*) I’ve found the whole Serverless architecture to be a really cool concept, a nice cost-savings,
and an easy way to scale assuming you can organize your work around it. Although I hesitate to
say it’s the “next big thing” I am personally advocating for it and moving what projects I can to
it.

Tools

Build: nodemon
Testing: nothing fancy
Hosting: AWS (pretty much exclusively)
Version Control: Git, via GitHub (love unlimited private repos)
Editor: Atom, Vim (I’m terrible at it, but we all start somewhere)
As of October 25th, 2015

Front:

HTML (JSX)
CSS (Sass/LESS, Bootflat)
JavaScript (React, react-router)
Back:

Node.js (Express.js, Passport.js if I have users to store)

PostgreSQL (Sequelize.js or pg)
Tools:

Build: Gulp, Browserify, Nodemon

Testing: Jasmine
Hosting: Heroku (test), DigitalOcean (simple app), AWS (complex app)
Version Control: Git
Editor: Atom
This is the structure for the majority of applications I deal with today. It allows me to get up and
running fairly quickly and allows me to reason about the majority of my functionality using
JavaScript. PSQL allows me to handle relational and non-relational data fairly well in a single
database.
38k Views · View Upvotes · Answer requested by Patrick Lau
Share
Jacob Jay
Jacob Jay, entrepreneur, grokking HTML since '96, wrote my own web stack in '12
Written Dec 26, 2015
I mostly wrote my own stack. Yep.

It took a few years, but when you keep repeating the same patterns and running up against the
same walls (e.g. routing, auth) on different stacks (e.g. Java, Node), yet perhaps idealistically
want optimisations, there's little else to compete in terms of growing your understanding of the
entire chain and its protocols. Doing this is what made me confident in moving from being a
software developer to a software architect. Don't jump on a stack bandwagon.

My stack thus became (released as Moonstalk):

Linux and/or OS X
Lighttpd (but adopting Nginx)
FastCGI (why have multiple cores if you're not using them?)
Lua (webapp runtimes, libraries)
Lua Pages (customised document templating and dynamic markup)
Lua (datastore runtime and functions with SQLite for persistence)
My toolchain:

Terminal/Console
Mercurial (and a graphical client, plus mergetool)
A graphical code editor (that supports custom markup hilighting and code completion)
Many will argue this is not very modern. I agree. It leaves me in control. Nothing is lost to me,
I'm not letting something else package up and munge javascript and css or handout database
access indiscriminately. (That said it can of course all be customised.) As such the architecture is
server-driven so supports adaptive web development, rather than the predominant current trend
favouring client-side (in fact the DB is not directly exposed to clients).

As to the language, I actually started out as a simpleton (designer) so wanted something elegant,
performant and dynamic. PHP plain sucks (although gets a job done). Javascript isn't at all bad
(has minimal function overhead, but all the tricks and exceptions make it hard to get to grips with
as an ambitious beginner) and the MEAN stack competes really well. Rails is just too much
(although IBM's JVM OMR holds promise of alleviation, just as HipHop did for PHP).

Lua fit the bill (its function overhead is higher, but it hooks back to C for important stuff).

Response times in my stack are typically 1–3ms (with DB queries). This is important to me. I'm
not asking a user to wait 500ms for a product page because the runtime and DB can't work
together properly. Tighter integration is needed for proper UX. We're not just developers, full-
stack means we're responsible for delivering on user's expectations as well as the business
requirements. One shouldn't trump the other.

ORM typically has an unacceptable overhead. My database uses native Lua tables, which go back
and forth to pages much the same as is possible with Mongo, except it's all native Lua so no
database queries. Yes there's a limit: RAM. But it is fracking cheap, and if you're building
something so big you shouldn't be using Mongo either. (I've a lot todo on my DB, loading is
abysmally slow, and it needs replication and delegation, websockets would be nice too, but
neither here nor there for most standalone sites.)
Yeah I haven't addressed stuff like form validation and all the other things many frameworks
throw in (although my release does includes some very basic helper functions for doing this both
client and server side) as these are something that ends up being quite specific to a developer and
thus best left to them to learn, or throw in.

Just as this stack made me reflect upon my designs for prior platforms in the abstract sense, I
encourage you to look beyond a stack, ask yourself how each component integrates and why.
Everything started as one developer's own very specific solution to their problem. If you want to
grow, develop holistically.
10.9k Views · View Upvotes
Share
Justen Robertson
Justen Robertson, Senior Web Developer & Freelancer
Written Oct 14, 2015
The main two stacks I use are LAMP and MEAN, but I've been known to mix and match all
kinds of technologies depending on the use case.

For example, one project was primarily a PHP-based CMS running on LAMP, but it needed a
high-performance, high-capacity live chat feature which PHP+MySQL sucks at. So I
implemented that using Nodejs+socket.io+memcached, with the Nodejs module also using
MySQL to access user authentication information.

I usually run on top of CentOS in production environments, but I've also used Debian/Ubuntu
server in a few places. Personally I prefer CentOS. I manage a rack of dedicated servers as well as
some virtual machines in Amazon EC2.
9k Views · View Upvotes · Answer requested by