Choosing the right platform to develop your website or web application can mean the difference between creating a flexible application that reduces long term costs or feeling like you are in a jail cell and serving 20 years to life. Alright, that's an exaggeration but you've heard the nightmares from Entrepreneurs and Small Business website owners who have tried to build a something online only to be told of numerous issues they had in developing the platform.
Choosing the right platform to develop your website or web application can mean the difference between creating a flexible application that reduces long term costs or feeling like you are in a jail cell and serving 20 years to life. Alright, that's an exaggeration but you've heard the nightmares from Entrepreneurs and Small Business website owners who have tried to build a something online only to be told of numerous issues they had in developing the platform.
Many of these issues could have been handled from the start by choosing the right web development team as well as choosing the right platform to build your application or website on.
In today's market there are many tools and platforms available for building web sites and web applications. The most widely used platforms can be classified as one of three types:
A Content Management System provides a work flow for deploying and managing specific types of web sites such as blogs or forums. A CMS is designed to leverage the skills of a site's administrator at the cost of flexibility and code control. The goal is to allow you to manage your website content through a user friendly interface without requiring a web developer. A CMS will usually provide some tools for a developer to create a custom theme or template. Beyond that, adding additional functionality is typically cumbersome for developers and costly for site owners.
Examples: Most of these have gone away. WordPress 2 was a CMS but WordPress 3 is a CMF. This comes in when a developer wrote something custom that allows you to edit your content and that's it.
A content management framework or CMF is much like a CMS. It is designed to be more flexible than a CMS and provides some mechanisms for developers to extend its functionality. While it is more flexible than a CMS, it is much less flexible than a web application framework and typically does not perform as well.
Examples: WordPress 3+ and Drupal
A web application framework provides code based utilities and workflows for developing custom web applications. A web application framework is designed to leverage development skills and enable the rapid development of custom applications. It allows you to build much more complex and performant applications than a CMS or CMF but also requires much more expertise to utilize.
Examples: Rails is a Ruby framework. Cake, Starbug, Zend, and CodeIgniter are PHP frameworks
When choosing a platform it comes down to the complexity of the project, amount of control you want, and the skills at your disposal. If you are an expert web developer or have one at your disposal, then unless you are trying to build a very standard type of web site, a CMS will only slow you down and end up costing the client more in the long run because you may be fighting against the CMS to do what the client wants as far as functionality and therefore even a small feature request could require bypassing what the CMS is allowing and then building the feature.
Here are a couple of ways to think about it:
The rub comes when a CMF will do 95% of what you need. Is it better to step it up to a Web Application Framework or is it better to stick with the CMF and then understand that you'll get pretty close to what you want but may not be able to get to exactly what you want?
This is where the relationship and processes of your web development firm play a huge role. They should be able to help you choose what's best and explain why they are making their suggestion. It comes down to knowing your development team is experienced and looking out for your best interest.
When building a custom web application you need to consider the type of database that best suits the data. Here's a quick guide on the differences between MySQL (Relational) and MongoDB (Non-Relational / NoSQL).
It was back in 2004 that Ruby on Rails first came out and popularized web application frameworks. What you might not know, is that it also popularized ORM (Object-Relational Mapping) layers with its ActiveRecord object. An ORM layer basically provides an object oriented interface to a relational database. That means that instead of writing a query to insert or update a record, you assign some properties to an object and call a save method. Instead of writing queries with joins, you can access related data through properties of an object.
For example, if you have a "post" object that represents a blog post, you can access it's comments through the property "post.comments". At first appearance, this might seem delightfully convenient, and to some extent it is. Fast forward a few years, and just about every web application framework out there implements an ORM layer. It lets you access relational data in a way that is convenient for your application. The problem, however, is that this is horribly inefficient and it teaches developers to ignore how the underlying database works. In fact, it's so inefficient that it just about killed relational database systems altogether.
Thankfully, we never jumped on to the ORM bandwagon. Since then, many alternative database systems have been released. One of my favorites is MongoDB. Let's look at some of the differences between MongoDB and a relational system like MySQL.
MySQL represents data in tables and rows.
MongoDB represents data as collections of JSON documents.
If you think about it, a JSON document is very much like what you would be working with in your application layer. If you are using javascript, it's exactly what you're working with. If you're using PHP, it's just like an associative array. If you're using python, its just like a dictionary object.
The SQL in MySQL stands for Structured Query Language. That's because you have to put together a string in this query language that is parsed by the database system. This is what makes SQL injection attacks possible.
MongoDB uses object querying. By that I mean you pass it a document to explain what you are querying for. There isn't any language to parse. If you're already familiar with SQL, it'll take a little bit of time to wrap your brain around this concept, but once you figure it out, it feels a lot more intuitive.
One of the best things about MySQL and relational databases in general is the almighty JOIN operation. This allows you to perform queries across multiple tables.
MongoDB does not support joins, but it does multi-dimensional data types such as arrays and even other documents. Placing one document inside another is referred to as embedding. For example, if you were to create a blog using MySQL, you would have a table for posts and a table for comments. In MongoDB you might have a single collection of posts, and an array of comments within each post.
Another great thing about MySQL is its support for atomic transactions. The ability to contain multiple operations within a transaction and roll back the whole thing as if it were a single operation.
MongoDB does not support transactions, but single operations are atomic.
MySQL requires you to define your tables and columns before you can store anything, and every row in a table must have the same columns.
One of my favorite things about MongoDB is that you don't define the schema. You just drop in documents, and two documents within a collection don't even need to have the same fields.
In MySQL there is really isn't much flexibility in how you structure your data if you follow normalization standards. The idea is not to prefer any specific application pattern.
In MongoDB, you have to use embedding and linking instead of joins and you don't have transactions. This means you have to optimize your schema based on how your application will access the data. This is probably pretty scary to MySQL experts, but if you continue reading, you'll see there is a place for both MySQL and MongoDB.
MySQL often gets blamed for poor performance. Well, if you are using an ORM, performance will likely suffer. If you are using a simple database wrapper and you've indexed your data correctly, you'll get good performance
By sacrificing things like joins and providing excellent tools for performance analysis, MongoDB can perform much better than a relational database. You still need to index your data and the truth is that the vast majority applications out there don't have enough data to notice the difference.
If your data structure fits nicely into tables and rows, MySQL will offer you robust and easy interaction with your data. If it's performance that is your concern, there is a good chance you don't really need MongoDB. Most likely, you just need to index your data properly. If you require SQL or transactions, you'll have to stick with MySQL.
If your data seems complex to model in a relational database system, or if you find yourself de-normalizing your database schema or coding around performance issues you should consider using MongoDB. If you find yourself trying to store serialized arrays or JSON objects, that's a good sign that you are better off MongoDB. If you can't pre-define your schema or you want to store records in the same collection that have different fields, that's another good reason.
You probably thought this was going to be all about performance, but MySQL and MongoDB are both tremendously useful, and there are much more important differences in their basic operations than simply performance. It really comes down to the needs of your specific application.
Developing new software can be a frustrating and tricky process if you aren't prepared and don't have a game plan. When you go into it unprepared the chances of finishing the project or having it run smoothly are unlikely.
To help you we have broken down successful software development into specific activities:
Planning is first and always should be. Many less experienced developers or clients will want to jump right to the Implementation stage and skip planning. The point of planning is to hash out ideas and come up with a game plan. Think of a professional football team, they take the field with a playbook that they've already hashed out and run several times. If they were to take the field without a plan, they would be slaughtered.
In the case of software development, slaughtered means budget overruns, launch delays and a buggy product that may not be suitable for use.
By planning correctly, you can define the most important aspects of the software that must be there for launch. You can also decide how things should work, in which case it only has to be developed once. That saves time and money.
After you've decided on the game plan you go out there and take action. This can take on many different forms but in essence, it means designing the graphics or actually writing code. Regardless of the platform or language, you are building at this stage.
Testing could technically be considered part of the implementation stage because it is done as pieces of the code are completed. There's are various types and stages of testing but the goal is to find defects as early in the process as possible so that they do not make it into future versions of code where they could have a greater impact.
Think of it this way. If you are building a car, you want to find out that there's a problem with the engine before you build out the drive shaft and the transmission, otherwise, there's a possibility that fixing the engine defect may require you to rebuild the transmission and drive shaft. Find it early, fix it early, and continually build on good code.
This is a step that many companies do not use, but the successful ones do. It is essentially going back through the code and cleaning things up. You are making it more efficient and continually improving upon it by making it simpler and simpler. The way it behaves is the same but you may be able to take some code and refactor it down so that it’s easier to extend and maintain. An example of a company that does a lot of refactoring? Facebook.
Deployment is the point where the code has been approved, reviewed, and ready to be pushed to the production environment. Otherwise known as "the live site"; This is where everything is pushed live and your clients and customers start to use it.
After deployment, you're at the point where you've learned what's working and what's not and require some updates or changes based on your business needs or client needs. The big project is done and now its upkeep and staying current.
There are many other pieces of the software development process that we left out, this is just a simplistic overview of the process. The end goal though is to partner with a development company that has a refined process that ensures success. You are in good hands if a company has been there and done it.
