What technology stack would you use to build web apps today?

General Web Dev
1

So let’s take a hypothetical business that wants to create a web program, or app, or whatever you want to call it. Let’s say my company SuperBizCool is going to create a simple online budget finance tool. Here are some specs on the app and its use:

  1. The entire application is free to use, most likely supported by simple website ads or a few sponsored ads/partners.
  2. People can use it anonymously but their data won’t be saved if they do. Otherwise, it needs a user account structure.
  3. The app will be expected to be used across all modern interfaces and have modern behaviors such as:
    a: Use from primary website, Android, IOS, Windows, Mac, all browsers, etc.
    b: Single sign on with Facebook, Twitter etc if desired.
    c: Modern interface and data manipulations with Ajax, drag and drop, jscript, jquery or whatever (minimize page refreshes)
    d: Data needs on a per-user basis are not huge, but projected user base could be millions.
  4. The application should be built on solid and lasting technologies, no “just came out” tools or fly-by-night services or “developed and maintained by this one guy in Sweden” libraries.
  5. As a finance app, we’ll be sure to use tabular data, reporting, printing/PDFs, charts/graphs, and possibly communicate with other 3rd party APIs.
  6. Scalability. As popularity grows, the foundation should scale with it. The servers, availability, speeds, database should all be able to grow and expand as the project grows, without needing in-house IT to manage. This means hosting the project on an inexpensive platform that can grow with the company endlessly.

If you read Sitepoint for any length of time or get the “Versioning” newsletter, you will be bombarded daily with this new tech and that new service and this new framework and that new database and this new cloud and that new package and this new library etc etc etc. An endless flow of “cool stuff” that no web developer or programmer could even use in a lifetime.
My question is this, given the specifications above for a company that wants to build a modern application, what would be the best technology stack to go with these days?

Server? Classic virtualized Linux OSes? A “cloud app” server? Heroku? AWS? Azure?
Database? Use Hadoop clusters? MySQL? Redis? NoSQL? Relational?
Primary programming stack? PHP/jscript? RoR? Python? Java?
Use any frameworks for the API or build from scratch? Phalcon? Django? Node.js?
Frontend framework? ext.js? Angularjs? ionic? None/Bootstrap?

There are so many technologies, serving platforms, frameworks to choose from, but if you were building a modern app TODAY and and could start fresh with the best solid tools, what would you use and why?

5 Likes
2

My current Personal Project for the last few months is being built in Play Framework using Scala, with a SASS & Foundation frontend, and a PostgreSQL database. It’s currently being published on Heroku. It’s based around user uploaded images, so I built my own image server on a VPS instead of using S3 or something like that.

I have plans on moving to AngularJS when I get the initial piece out the door, since I’m not that familiar with it yet I didn’t want to overwhelm myself. When the time comes that I outgrow using a standard database and simple caching, I will move pieces into Redis. But right now, that would just be over-optimization. I have some important things being stored in a basic memory cache, but that’s just meant to be temporary.

This project will hopefully turn a profit, but if it doesn’t it was a good way to experiment and learn. I have learned that Scala is pretty nice, but it’s not really what I thought it was. I don’t really regret using it, but I can’t say I’m a big fan. If I were to do it all over again from scratch, I would probably use Express, Sails, or Django. I would like to use Spring Boot, but right now it’s still too immature and too much is changing for it to be a consideration.

The application should be built on solid and lasting technologies, no “just came out” tools or fly-by-night services or “developed and maintained by this one guy in Sweden” libraries.

I find this an unreasonable constraint. Sites should be build modularly and able to grow and adapt as the years go by. What the site is in 5yrs should not be what it was in the beginning, especially if you’re using Agile methods. Sites and applications go through different stages, putting too many constraints on the early development stages leads to missed deadlines and vaporware.

I agree that some people completely overuse and rely too heavily on 3rd party plugins though.

1 Like
3

I think the YouPorn rewrite 2-ish years ago made excellent architecture choices, and I think those would still be excellent choices today for a new app.

3 Likes
4

This was a good talk, but you have to ask yourself 1 question…

If you’re already at 300 million page views a day and one of the largest sites on the internet, is that really scaling?

I mean I guess it is technically because it’s obviously still going to grow, but there’s no way a normal product is going to have that much forethought put into such a robust architecture up front. To me, scaling would be from those first few thousand views a day up to a few million. Most small startups and small teams don’t have the time or resources to spend 3 months just figuring out proper load balancing and massive amounts of data output, nor do they really need to since it’s going to be a while before they need to use it and by the time they do, things may have changed, the business may have changed, and the best technology probably has changed too.

I mean if you have a team of 25-50 talented people and a $100mil+ budget from the get-go, then sure doing all this up front would be awesome. Most don’t really have this luxury. Doing as much as you can with the little that you have, is a priority and being able to accommodate those changes in the future is a far cry from actually developing them before any code is written and having those things in your mind while you’re writing and making decisions later on.

2 Likes
5

That is an interesting thought on scaling, because when you look at most serious app-hosting companies today, they sell you up on their easy “scaling” architecture. It’s not uncommon for their marketing to suggest you can scale endlessly into the millions of users a day just by moving some sliders in your account and they take care of the rest.

No longer do you NEED the 25 talented IT nerds to build database server clusters, cause these companies do all that for you right?

Vertical scaling is almost completely painless, something like a Digital Ocean droplet or an AWS or Azure server can be boosted with a slider and a button with likely no downtime. Horizontal scaling I’m not so sure. If AWS or whoever provides that type of scaling/clustering as part of their service, it shouldn’t be that complex either.

Or is the marketing just lying? AWS is supposed to be that limitless resource of power isn’t it?

1 Like
6

Right soooo.

Ruby backend probably, at least to start with. If later on the application hits capacity and it reaches the limit of ruby, it can be dealt with then. Single monolithic app, no services at this point. App would be responsible for serving up an API which would be consumed by probably a React or Angular front end. UUIDs are a must.

Hard to go wrong with PostgreSQL at this point. But I would probably do it more in a CQRS structure. Separating my reads from my wrights. Events come in, aggregators listen for events they care about and then populate projections tailored to the queries that are needed. ie: Comment Projection would be a list of comments, with user info. If a user were to update their username, an aggregator would be solely responsible for updating the users info in every instance in those projections. Projections would power api endpoints. New endpoint, new projection. Store the info in the way you want to consume it. Possibly caching certain queries in redis.

at this point our applications artictecturhe looks sort of like this:

Front End → Action by user → Aggregators Deals with Action → Projections Get Updated → Front End gets updated data.

Projections dont have to be PostgreSQL, they could be any sort of store that is optimised to server the data in the required format quickly. Not all projections have to be the same either. One could be Mongo or Redis if you wanted. They can be versioned and scaled horizontally with master slaves. The original PostgreSQL is pretty much just there for storing events in a repayable idempotent way.

As the application grows we can then pull out services (aggregators/projections) to increase performance and scalability. As long as they can subscribe to the events, they can be written in anything you or your team at this point wants, GO, Erlang, Scala, .net, doesnt really matter as long as something like the load balancer or a routing layer can point API endpoints at them.

But start simple, single app, events, UUIDs, api, solid front end, single domain. Event comes in, projections get updated, single api endpoint maps to single projection. A comment projection shouldnt have to ask about the users info, it should already know.

2 Likes
7

Heroku has sliders too, they call them Dynos.

These things aren’t endless, but I’m sure they would take any amount of money you’re willing to send them. Even though these can grow very large I imagine at some point it’s no longer cost effective to use these types of services, especially if you’re doing something different or something special other than just serving web pages like YP is.

8

Really good questions but there’s no answer I’m afraid. This is why it’s so important to always be learning in this industry - there a million options and the best developers are the one’s who can select tools that reduce complexity and increase productivity.

What experience does the team at SuperBizCool have? If they are expert in one stack already then that’s what you should stick with unless it’s really out of date. It’s really difficult to change an animals spots if they’re decidedly a Microsoft / PHP / Rails shop or whatever - the team will likely have their preferences already.

Any of the current stacks are up to the task of building a web app, I’d most likely pick one from these for the backend however:

Ruby / Rails
Python / Django
PHP / Laravel
.NET / MVC

The first three get an edge over the Microsoft stack in my mind because there’s a certain lock-in with ms tech that isn’t desirable from the outset. As much as possible you want to be using free open source trusted tech like Ubuntu / Postgres / Nginx / Redis etc… You can use newer tech for select parts of your application - Node / socket.io / mongo might be perfect for chat or notifications for example but I wouldn’t build an entire application on the node stack as the complexity is higher.

And these from the front-end

Backbone
Angular.js
Ember.js

You need to ask yourself if your app will have a level of sophistication on the front-end to warrant a framework like these. If your team has a high proficiency in Javascript they’ll know when these tools benefit the app and simplify the code you need to write or burden it with added complexity.

Modern interface and data manipulations with Ajax, drag and drop, jscript, jquery or whatever (minimize page refreshes)

It’s possible to keep things really simple with jQuery and bunch of plugins - if the app reaches a level of complexity it’s likely you would have benefited from the framework.

All these options and considerations is why we are required to make calls on them and back them up with working software. That should always be the yard stick of comparison. It’s far more important to get the team right than the tech though. If you have a good team just trust them on the best tech to use.

1 Like
9

It is important to choose the right mix of technology for the right set of requirements while building a web application from scratch. Almost all companies need to do a legwork before they choose a technology when a new project lands.

But what constitutes the right decision? It is your ability to scrutinize requirement and ensure that the use of technology is well in budget and is efficient, secured and scalable.

Following are the technologies that you can think of while making a decision:
Basic Frameworks: Laravel, ASP.NET, Ruby on Rails (All server side), AngularJS, Silverlight (both client-side)
You can also select a platform if the solution demands. This includes Magento, Zencart, Joomla (for eCommerce), Sitefinity, Umbraco (for CMS) and Drupal, Moodle, etc. (for LMS).

A hack: Always choose a solution bound technology when possible. Choose basic framework, only if there are no solution-based frameworks meeting (most of) your requirements.

11

@hnrindani Thanks for you comment. But this thread is 3yrs old and is not really relevant today. Please start a new thread if you’d like to discuss this topic further.

Even so… a few things in your post were outdated and should absolutely not be used. Silverlight, for example, has almost universally been unsupported for many years, including in Microsoft’s own Edge browser.