By Keith Chima / 4 Jan 2016 / Topics: Application development As a service
My goal for this article is to highlight which questions you should be concerned with when choosing these technologies, and in which order. Although this isn't a “paint-by-numbers” guide that will spit out what technologies you should use for your individual project, this post will make the process of choosing technologies a bit less overwhelming.
The first thing you have to do is make clear the goals of your project and write them down. Is it internal or customer-facing? If it’s customer-facing, is it for web, desktop or mobile?
Think of the key features it needs to support: Does it need to be a “one-page” app (meaning you might want to use a JavaScript technology like AngularJS)? Do you need to support login/authentication or single sign-on for social media integration? These can be tricky and will likely be something you want to avoid implementing yourself by using technologies such as Disqus or OpenID. In the case, where your goals are specific, make a note of whether they're strict requirements or conveniences.
Other goals to take into consideration are cost, performance, promotion, portfolio building and education. This list of goals can be as simple or as comprehensive as you want to make it, but I recommend a short list with a few goals ordered by priority. This should help you make judgment calls and any necessary sacrifices.
Once you're finished outlining your goals, you can begin selecting technologies. These fall into two major categories: your development technologies and the target deployment platform. These constrain each other, so I usually recommend selecting development technologies first, as they're more likely to be inflexible (at least if you’re working on a personal project).
However, if you're working for a client who has an established deployment process, or if you're planning to make a mobile app, this decision might have already been made for you, in which case you'll need to select from preapproved or supported technologies.
Determine whether you actually need a front end, back end and database. Obviously, any of these that you can eliminate (without compromising on your major goals) can dramatically decrease your project’s complexity and cost, both in the short term (upfront dev costs) and long term (hosting).
Then, based on which of these you actually need, I'd make a list of front-end, back-end and database technologies your team knows or would be interested/willing to learn in the course of your project. Unless learning new technologies is the major goal of your project, I would try to keep unknown tech to a conservative level. Don’t try to learn a brand-new front-end, back-end and database technology all in the same project.
Examine how these technologies align with your goals. Obviously, if any of the must-have goals directly conflict with one of these technologies, it makes it easy to eliminate a few right away. Don’t get burned by fad technologies. There are developers whose goal is to learn the hip new language, whether for personal interest or to buff up their resume, but unless it has at least a few years of vetting, support and compatibility, it’s probably not worth risking a major project on it.
This applies to theoretically low-impact JavaScript plug-ins as well, to a lesser extent, although usually these are chosen later in the development lifecycle. I've been on teams that have lost weeks of developer time spinning their wheels on well-intentioned plug-ins.
By this point, your development technologies and languages should become pretty clear. Now it’s time to choose your deployment platform, assuming the decision hasn’t already been made for you.
If the decision hasn’t been dictated, you're more likely to be working on something like an independent web project. This means you have to decide if you're going to host everything yourself, set it up on some web host or use a more comprehensive Platform as a Service (PaaS) solution such as AWS, Google App Engine or Azure. This usually comes down to a personal preference between cheap/open and comprehensive/secure/easy.
More and more, I prefer these comprehensive PaaS solutions in pretty much all cases. Many of these services have free tiers that can host many apps almost entirely. Furthermore, they take care of a lot of the additional concerns for an application, such as security, scalability, cron jobs and logging with easy-to-use interfaces accessible from anywhere. And many of these services will offer you their “content-delivery network,” which will deliver your app to users much faster than the alternative. Many developers may not want to spend time implementing such things manually.
The obvious trade-off is that you may find yourself spending time optimizing everything for that one host to minimize cost and meet any restrictions associated with that platform. Aside from potentially locking you into a host long term, this can also eat a decent chunk of time, which hurts the argument for using PaaS in the first place.
Fortunately, optimizations designed to reduce cost in a PaaS, such as eliminating unnecessary database queries and caching as much information as possible, are often best practices for customer experience and development in general. Your app will also benefit in other ways from these optimizations. And you may be able to avoid lock-in with logical cloud management tools such as OpenStack.
When choosing a PaaS provider, you'll want to look back at your preferred development technologies. Which of the providers supports most or all of your preferred technologies? Take special care to look at database support.
Unfortunately, the deployment platform may occasionally trump your preferred development tech, and you may have to revisit it. An example of this is Google App Engine locking you into using its Google Datastore rather than a conventional database. You may often find in these PaaS providers that, while it may be possible to customize the technologies you want, it's often significantly more expensive.
To make these judgment calls, look back at your prioritized list of goals. When this project is released, will it be put into the hands of someone less technically capable than yourself, who may not be very good at digging through databases or logs? If so, you may want to opt toward a PaaS with a nice dashboard, such as Google App Engine. Do you need logging or cron jobs? How secure does it need to be? And how capable is your team at establishing a secure application? What is the budget?
An oft-overlooked factor is ease of deployment. It can be very nice to be able to deploy everything to your local, dev or production environment all with simple one-line commands. And, as it's smart to vet your individual technologies, it's wise to vet your tech stack as a whole to make sure the individual technologies play nicely with each other. It also ensures you'll have end-to-end tutorials and support for similar full-stack projects available online.
As developers, we usually want to get to the point in the project where we can compartmentalize and iterate as soon as possible. That can be difficult to do at the start of the project, so my goal was to subdivide the process into smaller, more digestible chunks. Hopefully, this post will help prevent major concerns and requirements from getting lost in the shuffle, or at least give developers a less overwhelming perspective on choosing their technologies.
Software Engineer
Keith is a full-stack Java/JavaScript software engineer and consultant in Insight's Columbus, Ohio, office.
