How to Reduce Risk in Web Development
How to Reduce Risk in Web Development
Join the DZone community and get the full member experience.Join For Free
Learn more about how CareerBuilder was able to resolve customer issues 5x faster by using Scalyr, the fastest log management tool on the market.
Web development can be an inherently risky endeavor. While the costs to get up and running with a development environment are almost non-existent, every choice you make as you build your application has long-term effects on your technology stack, your application’s performance, and the expertise available to you as you build a development team. Below we’ll look at a few strategies for reducing the risk inherent in web development. Applying these strategies may add some additional effort up front, but in the long run will reduce the total cost of ownership of your application and provide you a lot of flexibility when it comes to finding solutions to development and deployment issues.
Strategy 1 – Prototype Fast
At Facebook, one of the prevailing development philosophies is “Move fast and break things.” This mindset is not intended to produce low-quality code, but rather to encourage developers to be bold in their choices. The faster they get a new feature up and running, the faster they can figure out whether or not it resonates with the end user, and the faster any resulting infrastructure problems can be resolved. Adopting a similar policy for prototyping in your web application shares similar benefits. The sooner you have a prototype of your application up and running, the sooner you can hold core dialogs with stakeholders and users regarding the direction your application is taken. This follows on from several development methodologies in wide use throughout the computer industry, and when leveraged properly it can allow your team to very quickly respond to requirement or architecture changes as they arise.
Strategy 2 – Own Your Data
Many web application developers are quick to outsource some of the more tedious aspects of their application’s functionality. From choosing a new gem in Rails that handles security to opting for a provider like Firebase that provides a scalable – but obfuscated – NoSQL data store, these choices can improve the iteration speed of your development team, tying in with Strategy 1 – Prototype Fast. However, these types of changes can be limiting, and transferring to an alternative solution once your application has gained traction can prove troublesome.
Along these lines, it is important to take ownership of your data store as soon as you are able to devote the resources. This involves owning the data itself, and the interactions it has with your applications. Owning the data itself – even if it is stored on an external provider – is key to allowing your team the flexibility to transfer between various back-end providers. Moving from a Postgres instance on AWS to another hosting service, for example, is a lot easier than pulling data out of a web API that doesn’t give you access to the underlying data store. Along those lines, it is important to create an architectural separation between your application’s code and the underlying data store. If you plan your development with the data portion being an encapsulated component, you will find it easier to switch between providers when you run up against issues with scaling or provider infrastructure.
Strategy 3 – Follow Standards
Standards evolve in the industry as a set of agreements among developers and development organizations that, as a whole, allow service providers to make assumptions about application architecture and orient solutions around those assumptions. In web application development, the standard in question is using a RESTful API to structure your application. REST, or Representational State Transfer, is a standard oriented around creating a scalable web architecture. It uses the verbs built into the HTTP communications spec to represent state changes in your applications. For example, in a RESTful API you would create a new user object by using an HTTP POST request, which would return an ID. Each HTTP verb is mapped to a server action, in essence standardizing an interface for your web application. While this may result in more effort to implement up-front, the end result is that your application is more flexible to move between back-end providers when the time for change arises.
Strategy 4 – Using JSON for Web Communication
ConclusionThere’s no one way to develop a web application, and most times the only development decisions that make sense are the ones that you can get all of the key players to agree upon. However, there are several patterns that have proven themselves time and again, leading to more flexible and agile applications that can leverage a variety of services to achieve both cost savings and performance goals. By following the strategies above, you can ensure that your web application is ideally positioned to move where it is needed, from getting feedback on clients as soon as possible to changing the back-end of your application as easily as possible. While not every strategy is critical, making use of even one strategy will pay you back in increased development velocity, application robustness, and cost reduction capacity.
Published at DZone with permission of Itay Herskovits , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.