Choosing Web Development Framework

Zahir Koradia

Z….. says!

At EncycloKidia, we are building a web and mobile platform for enabling parents to find services for their kids. We are starting out from scratch, which is a rare opportunity — we carry no technical debt. A large number of decisions need to be taken when building a new web application: web framework, Javascript library/framework, web server, database engine, source control, code review system, build tools, deployment and provisioning tools, etc. We will cover EncycloKidia’s decisions on each of these, but for today, we will focus on how we chose our web development framework.

Web development has come a long way in the last 10 or so years. And with it have come forward a few different ways of building websites/web applications. Tools like WordPress, Drupal, and Joomla have made it very easy for people to build sites with minor tweaks. Within the world of building custom sites/webapps web development frameworks vary between philosophies (minimalist and flexible vs do-it-all), pre-packaged capabilities (ORM, templating, internationalization, provisioning), and programming languages (Ruby, Python, PHP, C#). Wikipedia has an extensive list of frameworks with a comparison of their capabilities. A little bit of searching will tell you that there is no single answer to the question. As such I don’t intend to provide one. Instead, I will share the factors we considered in choosing our framework: Django. Your answer need not be the same, but it is likely that you will want to give due attention to many of the factors listed below.

One thing that is quite unique about the list below is that we prioritize maintainability of our code over say scalability. We feel scalability is a problem best addressed when it is reached. There are enough tools out there (caching, sharding, load balancing web and database servers, CDNs) to help us scale when we need it. So without further ado, here is the list of factors we considered when choosing a web framework.

Open source: Our past experience shows that the ability to read and expand on existing framework is extremely important. This will help understand certain obscure aspects that are otherwise not documented or help identify bugs that can be fixed by/for the larger community of users.

Maturity of the framework: The framework needs to be at least a few years old, which combined with a large number of users is a good proxy for less bugs. But it shouldn’t be too old as the web development abstractions are evolving quickly and an older framework may not be adopting the new abstractions and expectations.

Good developer community: This is important for two purposes. First, a large enough developer community ensures that you get good support in learning advanced aspects of the framework, and any questions you have are answered. Second benefit of a large developer community is that you are likely to find good developers knowing the framework when you want to grow your technology team or want to hire developers on contract.

Manage database upgrades and rollbacks: Most non-trivial websites will need to make changes to their database schema as the site evolves. This is true for EncycloKidia too. I have already made over 30 database revisions in the first month of development. The web framework must allow migrating schema and related data from one version to another. We may occasionally need to rollback an upgrade too and the web framework must allow rolling back schema upgrades too.

Support for TDD/CI: Being able to automate testing of different components of a website, one of which is its APIs, is important to ensure quality and faster update rates. The web framework should make it easy to write tests and have reasonable support to enable a continuous integration tool to use those tests.

REST APIs: We are going to build a website as well as mobile apps for accessing and modifying data. Building REST APIs that can be accessed by a web front-end as well as a mobile app thus makes sense. Thus the framework needs to make it easy to build RESTful APIs.

Integration with searching technologies: EncycloKidia essentially provides a listing of children’s services. A significant amount of user time is expected to be spent searching and filtering children services/products. So a web framework that allows easy use of search technologies like Elasticsearch and Solr will increase development efficiency.

Integration with caching technologies: For the user experience to be good on EncycloKidia, search results need to be delivered quickly. With a small database the search responses may be quick; but when the data grows, the search speed may reduce. To improve performance search results may need to be cached. Good support for integration with caching technologies like Memcached and Redis will help at this point in time.

Developers’ previous experience: Being a start-up, optimum use of past experience of existing developers is extremely important. It allows the company to move quickly in the process of finding the product-market fit or in the process of scaling or building new features.

Ability to build and deploy quickly: Being a start-up we want to make the most of developer time in the early days of our existence. Thus, a web framework that takes care of as many things as possible in the task of building, deploying, and maintaining a website is preferred.

An additional factor that I came across on Quora was team size. If you have a large team size (may be 7+) then using a framework with minimalist and flexible philosophy may be better as it will make it easy for you to choose specific tools for each sub-task. If however your team size is small (1-5) then you may be better of with a do-it-all framework.

Have you come across other factors that affect your decision? Tell us about it in the comments.

More such posts are in the pipeline. If you would like to be intimated about them like us on Facebook and track our posts.

Digiprove sealCopyrightsecuredbyDigiprove2015
Bookmark the permalink.

2 Responses to Choosing Web Development Framework

  1. Stephen Henderson says:

    That’s a very good list.

    One alternative aspect of scale that I think _is_ worth considering from the start is how you organize your codebase as the application grows.

    This can be particularly problematic for all-in-one frameworks like Rails, and I imagine Django too though I’ve not used it. The tight coupling of controller/model/db which makes it so fast to get something up quickly can cause headaches later on if you’re not careful with organizing the code.

    An example would be having multiple ways of creating new user models – direct signup, facebook profile, twitter, google-id, etc. Do you have separate controllers for each one vs a monolithic user controller vs base user controller with sub-classes, etc. + how much logic goes into the model vs controller vs helpers etc.

    If done naively the code can easily become a spaghetti mess that’s hard to reason about and hard to add new features to, long before actual performance becomes a problem. If/when performance does become an issue it also makes it hard to separate out the components which do need to scale horizontally.

    Which isn’t to say it can’t be done, just that it’s something worth thinking about and coming with good practices for from the start. For Rails I highly recommend the book “Growing Rails Applications in Practice” by Henning Koch & Thomas Eisenbarth which covers this in depth. Even for non-rails users it’s a very good read on scaling large all-in-one web apps in general.

  2. Zahir Koradia says:

    Code organization is definitely an important consideration and is a bottleneck people hit way before scalability becomes a problem. I agree that Rails and Django make it easy for you end up with poorly organized code.

    It took me a few long running projects to figure out what parts of Django are worth sticking with and what parts best replaced with something else. For e.g. I have ended up completely discarding the template engine in favor of defining REST APIs and building out UI in a Javascript framework like Angular. Fortunately, there are people out there who take the time out think through good ways of organizing code bases and share the knowledge with us.

Leave a Reply

Your email address will not be published.

20 + = 21