How to choose a Web Application Framework, part 2
Selecting the right framework is a difficult decision that is fraught with consequences, since any change of course in mid-development can be costly.
This is the second and last part of the previous article on Web Application Frameworks, with a few more criteria to take into account when choosing your framework.
Compatibility with existing architecture
If you already have an enterprise architecture, you may want to use frameworks compatible with those already in place so you can re-use existing code, especially if the architecture already contains Web applications. For example, if you use Microsoft .NET for services that interact with the database or for business logic, you may want to choose ASP.NET for your Web applications. Besides, using the same or similar frameworks for the same programming language means a shorter learning curve for developers and a more uniform maintenance and updating process. Finally, if you plan on using a third-party hosting service, you may be restricted by the languages and frameworks it supports.
Flexibility may be an issue depending on the features you have in mind for your application. A flexible framework is easier to personalize, whether you’re using “hooks” or adding on in-house modules, for example. A framework that is excellent for some of the features you need but difficult or impossible to modify to add on the remaining features is going to be of no use to you. In this case, a less complete but more flexible solution is the way to go.
Every team or company has developers that master one or more frameworks particularly well. This consideration is a weighty one. Existing skills means a shorter learning and adaptation curve for at least one member of the team. Further, that member can become a go-to resource for other, less experienced colleagues. Experience also means you’ll avoid the most common errors and implement best practices early on.
Ease of deployment and configuration
Not all frameworks are created equal when it comes to ease of installation. Happily, for the last few years, thanks to the growing popularity of container platforms like Docker, putting applications in operation (deployment) is now a simple and uniform process, as long as you know how the platform works. If, for some reason, you decide not to use containers, opting instead for more traditional virtual machines, the process will be completely different. Therefore, at the exploratory stage, make sure you consider the effort required to implement the various frameworks, including configuration complexity. This will save you time over the long run, including at each application update.
The last, but not least, criterion is framework security. Usually, Web applications save and store user data, which may be vulnerable to hacking. Your chosen framework must offer the latest security features, including the latest encryption algorithms and password hashes. Also, check if HTTPS is supported on the latest version of TLS and SHA-2 for certificate purposes. Finally, since security loopholes are discovered on a regular basis, make sure you use a framework that is regularly updated to close loopholes as soon as they are flagged. Finally, remember to take every precaution when adding plug-ins later on, since they can introduce chinks in your armour, as WordPress discovered to its dismay.