Choosing a JavaScript Framework

Building your strategy

Chapter 2: Building your strategy

Now that you’ve thought a bit about the right questions to ask, in this chapter, I’ll present an exercise to help you put some values or quantifications on those observations.

You can download these questions at http://bit.ly/1g6kDSS, where you can make a copy of the spreadsheet (File > Make a copy) for your own usage or customizations. You’ll break down the requirements discussed in the last chapter into three categories: business, technical, and team.

Business

Audience/User needs

What are the top goals for delivery to your user/audience?

Business priorities

Top priorities from interviews; SEO, performance, etc. Only a few items to maintain focus.

Technical

Server-side development

What language/stack do you plan to have on the server-side?

Operations

Management, deployment, reliability requirements

Data

Sources, permissions, size (database)

Testing

How will you run quality assurance (QA)? Unit/functional/integration testing?

Team

How many engineers?

How many project managers?

How many visual designers or is it outsourced? How much communication do you have between your teams?

Operations staff? QA?

If you need to put some team members in multiple buckets (dedicate one engineer 1/2 to QA for example), be sure to note that.

Team top skills

Do they have core JavaScript skills? Where do their strengths lie?

Team professional interests

When you interview your team, what do they "no" and "yes!"

Business

In these questions, synthesize your interviews with the product stakeholders into solid needs and requirements. How does the product serve its audience?

Realtor’s and Co.’s new web experience simplifies access to important data for realtors and prospective clients and buyers. It is accessible wherever a realtor may be, and is easily found on search engines.

Technical

Given that this is a technical book, you can spend a little more time in the technical requirements.

Server-side

Decide what language/strategy you will have on the server side. For most large client-side JavaScript projects, providing a REST-API makes the most sense to interact with your data on the client-side.

When in doubt on the server-side, go with what you know. You can serve a client-side framework on practically any back-end stack. Traditionally (if there are any traditions in client-side JavaScript frameworks), some frameworks are used more often with some back-end configurations, such as BackboneJS and Ruby on Rails. There’s even a site dedicated to Backbone with Rails tutorials and many developers add CoffeeScript to that combination, which makes JavaScript feel a bit more Ruby-esque.

Depending on how you’re getting your data, there’s a good chance you don’t need backend frameworks as large as Django or Rails. Flask or Sinatra, small frameworks for Python and Ruby respectively, can (and do, for many applications) back strong APIs. It all depends on how much server-side processing your application needs to service the client-side; it can range from very little (small API framework) to a lot (Java backend to handle proprietary algorithms).

Realtors and Co.’s backend will be a lightweight (but well-secured) Flask application. Their go-to IT support person knows some Python, so they’re comfortable with it being used and have the ability to do minor maintenance when needed.

Determining your server-side strategy leads into your server-side reliability, deployment strategy, and other factors to work with your operations team.

Operations

Your operations team (even if that’s just you) needs to ensure security, deployability, and reliability for your application. As someone who mostly works in the middle and client-side of the stack, I have tremendous respect for operations, and they’re crucial to success.

Realtors & Co. Operations

Hosting is outsourced to a managed hosting company at Realtors & Co., so anything they use is informed by if their host supports it. Luckily, their host is flexible, supporting PHP, Python, and Ruby on a Linux stack; other configurations are not supported by customer service.

Since we’ve decided on Python as the server-side language, we can use the same language for server configuration to make deployment easier, and the managed hosting company is responsible for reliability and uptime of their servers.

Data

Your data is another (extremely) important exploration. What kind of data will you have? What are you storing? How much of it will there be? Determine your choice of database (or not) and help you consider how you will model your data through the back and frontend of your application.

Depending on how you’re going to store data, or what kind of data you need to store, you’ll decide how to design your API or other interface (but generally with your good buddy The Server) to interact from the client-side to the server-side.

Realtors & Co, will be storing some public and private data. A realtor should be able to see the offers and prices of a property, and if those have changed over time (they agreed that the most recent change is a fine view to start with).

The firm is growing, but currently only in one metropolitan area, and there aren’t plans to expand beyond that area yet, and they have about 40-60 properties on the market at a time. We’ll use a database our developers are comfortable with, PostgreSQL, to store and secure the data.

Testing

Determine who’s responsible for quality assurance (here and in the Team section). Identify who will be responsible on your team, even if they’re responsible for monitoring uTest (now Applause) after internal testing.

Also identify how you’re testing programmatically. A few of the major frameworks come with test frameworks, and there are many friendly, easy-to-use test frameworks such that deciding if you’re going to test isn’t a question. For now, before you choose your framework, you should plan to test your back-end code and be sure you accounted for testing time in any time estimates for engineering work.

Team

In this part of the form, the first few questions are simple numbers. How many people do you have for the necessary work? If you use time estimation methods, this will allow you to estimate approximate project completion time.

There are a couple questions about team preferences. If you didn’t talk with your team that’s doing the work during the requirements gathering process, now’s the time. If you share a proposal and your team shoots it down immediately, that’s a future motivation (and therefore velocity) problem.

The team building the new Realtors and Co. experience has outsourced visual design and is handling user experience design themselves. There are 5 multi-skilled individuals who will be sharing the work of the project. We assigned one to be lead on QA as part of their responsibilities, and one each to programmatic testing, operations and security, and data management (protecting the database).

With this allotment, we estimate a 3-month development process. The two weeks will be largely experience design and prototyping, the middle month and a half for core development with iterative QA, and the last month allotted for final work, small change orders, and final QA.

Strategy culling phase

Once you have the numbers down, it’s time to take a (semi-)final look at your requirements as it is. Can you punt any of your requirements to a later iteration (remember MVP)? In the next chapter, you’ll dig into the frameworks in action, seeing some sample implementations to help you see what might fit your unique case.