The Objective Blog

Keep up with what we're thinking, reading, and doing.

Ready? Set? Deploy?

March 16th, 2020 - by Casey Harding - Salt Lake City, Utah

Introduction

The big day has finally come. After months of planning meetings, design iterations, and development efforts, your web application is ready for launch! Discussions around deployment strategy and schedule are starting to take shape, but what does “deployment” mean, what does it entail, and what are some things to keep in mind as this milestone approaches?

Deployment: What Exactly Do You Mean?  

The word deployment is used in several contexts and can be more or less meaningful depending on what is actually being deployed. Technically speaking, a deployment is whenever new code or adjustments to existing code are pushed to the live site or application. As a user, it’s likely that you don’t notice the majority of deployments for some of your favorite apps, especially if the changes are minor or address background functionality and performance. It’s also extremely common to bundle and release multiple features and UI adjustments together; those reoccurring system updates for your phone or computer are great examples. Then, there are those extra-special deployments which are far more monumental: a completely new or rebuilt application is made public for the first time. This post is focused on this last deployment scenario. 

Save the Right Date

Imagine this: Everything’s ready to go. You schedule the deployment of your rebranded, rebuilt eCommerce store for Friday at 11:00 pm. On paper, this seems like a great time as it will hopefully mitigate the consequences of site downtime. However, when you go to check out the site early Saturday morning, all you see is a 500 server error message on what should be your store’s home page. In a panic, you try to contact the development team, but you aren’t able to get ahold of anyone. While this might sound like every business’ worst nightmare, this situation might have been avoided by simply scheduling the deployment for earlier in the week. We typically recommend deploying on a Monday or Tuesday and avoid setting deployment dates too close to holidays/weekends. If the new application will be replacing an existing product, scheduling a late-night deployment might be worth considering. If unanticipated bugs or errors are realized post-deployment, launching earlier in the week (either during or after business hours) provides greater assurance that the support team will be available to come to the rescue.

Getting to Launch: What’s Happening Behind the Scenes

  • Production environment setup and data migration (if applicable)
    Up until this point, your application has likely lived in a staging environment. A staging environment is a sort of “sandbox”, where functionality and interface improvements can be demoed, tested, and approved in a setting that resembles the eventual production environment.  That being said, there may be some configurations (for storage, performance, or security) that will come into play in the production environment but aren’t really needed for staging. Once a deployment date is determined, it’s time to get the application setup in a production environment, or in other words, on the server intended to house the public site. If real content or information was already inserted into the staging site but should also be present in the live application, some additional time needs to be set aside for data migration. 
  • Backup Configuration
    If your new application instance is replacing an existing one, it’s highly recommended to archive those old files in a safe place in case you need to roll back to the previous instance. It’s also a good time to get a backup schedule in place for the new application’s configuration files and database. In the event of a security breach or site crash, regular backups will mitigate data loss and help get your site up and running sooner. 
  • SSL Installation 
    SSL certificates offer an added layer of security to your web application by ensuring that all information passed between clients and servers is encrypted. Having SSL enabled has been an industry standard for quite some time and some search engines will go so far as to penalize your site for not having an SSL certificate in place. You can quickly tell whether or not a website has SSL enabled by looking at the address bar: the “s” in https:// indicates an SSL. To avoid potential penalties and to adhere to current security standards, we recommend that your web application has an SSL certificate installed either before or shortly after deployment.
  • DNS Updates
    In some cases, this is the final “switch” that will replace your old site with the new one. However, updating the DNS records is only required in a few common scenarios: 

    a. The application will use a new domain name that wasn’t in use previously. 
    b. The new application will be hosted on a different server than the domain was previously pointed to.
    c. Both a. and b.: The application will use a different domain name and will be hosted on a new/different server. 

    If the application will continue to use the same domain name and will reside on the same servers as the previous instance, there is no need to update the DNS records. In this case, the final “switch” will take place once all the new code files have been uploaded to the production server.

    In the event that a DNS switch is required and after the records have been updated, the only thing preventing you and the rest of the world from viewing the new site is the time it takes for those DNS changes to propagate. Hosting providers warn that this can take between 24 to 48 hours, but we usually see this transition happen much faster (between 15 minutes and an hour).

    Additionally, there are two other variables that may prolong the unveiling of your new site: TTL and caching. In the context of DNS, TTL is how often your domain is verified with the name server. It’s often set to 24 hours but can be manually adjusted through your hosting provider. Failing or forgetting to set TTL closer to 5 minutes might be the reason you aren’t seeing your new site right away. Secondly, if the issue seems to be isolated to a specific device, you may just need to clear your browsing history/caches/cookies or do a hard page refresh (holding down shift and clicking on the refresh/reload button on your web browser).

    To read more about domain names, DNS, and how website hosting works, check out one of our other posts here.

Some Other Pre-Deployment Items (if applicable)

  • Redirect strategy implementation
    If your web application is a rebuild, it’s likely that there are specific URLs (that users have bookmarked and google has indexed) that won’t exist on the new site. Prior to deployment, we’d recommend identifying these URLs and implementing a redirect strategy for each of those individual pages.
  • Email Setup
    Does your new site have a form that should send a message to a specific email inbox? Whether you are using a third-party service to manage submissions or not, verifying that transactional emails are set up and working in the production environment is important prior to launch. 

Conclusion

Deployments can come in all different shapes and sizes. The kind our clients tend to worry about the most involves the initial launch of a new or rebuilt application. If planned and scheduled properly, deployment days can be relatively seamless and uneventful (in a good way). 

The Database Dilemma: Part 2

February 19th, 2020 - by Casey Harding - Salt Lake City, Utah

If you missed it, in Part 1 we glossed over some of the benefits and limitations associated with the two prevailing database paradigms, relational and non-relational databases. In Part 2, we will give a more detailed analysis of the two approaches and give some suggestions when considering which to use. 

While the initial hype has diminished over the last few years, at one point there was a big push throughout the industry to replace the relational database with its non-relational counterpart. While relational databases were and still are powerful solutions, this pressure was not completely unfounded. With the ever-growing Internet of things and rampant increase of user activity on collaborative web applications, data in the 21st century have been generated and amassed like never before. “Big Data”, often unstructured or semi-structured in nature, has made it imperative for problem-solvers in certain spaces to employ an alternative, more flexible data paradigm. While there are certainly relevant use cases for non-relational databases, relational databases have retained their place as our go-to data store for most, if not all, of the web applications we develop.  

Why Relational Databases Are the Go-To 

Over the years, we’ve worked with hundreds of clients who come from vastly different industries. Through discovery conversations with our clients, we often are able to forge a pretty solid understanding of what data will be channeled into the application. At the same time, we can also determine, with some certainty, whether or not the data will likely remain relatively consistent over time. If the data appears to be mostly structured in nature and unlikely to dramatically change, we will more than likely suggest using a relational database. Data inputs that are clearly defined and have inherent associations marry well with the relational databases. Relational databases make it easy to optimize the relatedness of data sets and query the information in a rather streamlined, performant manner. 

Since all the information about a particular record lives within a single document in a non-relational database, it’s often difficult and computationally expensive to query for similar information stored across more than one document. With some of our non-relational database projects in the past, we have established joins on documents to mimic some of the behaviors and benefits that come from relational databases. However, this has often felt like a backward approach and we end up wishing we had just started with a relational database in the first place. 

When We Use Non-Relational Databases 

While relational databases seem to be the best fit for managing primary information collected and stored by web applications, more often than not, we will also utilize Redis and Elasticsearch for many custom web applications. Redis is a wicked fast key-value store, making it convenient for storing caching sessions. It can also be helpful in generating and scheduling task queues for background workers. Elasticsearch is another powerful implementation of a non-relational database. Known for its content flexibility, Elasticsearch allows for rapid and performant full-text search. Imposing a similar, comprehensive search of a relational database would require manual joins on all the tables or records you’d like to include, a process that can very easily become quite cumbersome.  Redis and Elasticsearch aside, if we come across a data architecture problem that would merit the use of a non-relational database, we would use one! Neo4j is excellent for graph-type data (think of user networks in social media platforms like Facebook or LinkedIn), MongoDB can be employed for unstructured “big data”, and DynamoDB is a handy key-value store.  

Our Recommendations   

  1. Know your data. We cannot stress this enough. Do everything possible to understand your data inside and out. Clearly defining your data set will not only help you to select the appropriate data paradigm but will also prepare you/your team with details that will likely impact the decisions you make throughout the project. 
  2. Map it out. If you’re caught in the middle, consider drafting a database schema. This brainstorming artifact and the process of creating it will likely provide valuable insight to support one approach or another. It may also highlight edge-cases in which retrieving groups of data might be more or less computationally expensive and/or complex to query. 
  3. Know your client/team. While this is and should be the least important factor in selecting a database, it’s certainly worth considering. In the case of agency work, it’s important that the solution is something the client is capable and willing to maintain in the long term. For in-house projects, selecting a database that your colleagues have working experience with may mitigate or eliminate the initial learning curve and potentially provide you with more resources to support the project in the short-term. 

Conclusion

When deciding on the appropriate data strategy for any given project, it’s extremely important to consider the consequences in terms of performance and data retrieval. While many factors can come into play, sometimes by virtue of a bad decision regarding the database, projects can require significantly more time and thereby impose avoidable frustration as budget and deadlines are stretched.

We’ve found that using both non-relational and relational databases can be extremely beneficial for the majority of applications we engineer: using relational databases as the primary solution for data that is relatively uniform and then employing non-relational databases for things like search and caching. As both paradigms evolve, it’s likely that the distinction between them will diminish. Until then, careful selection and utilization of both paradigms will greatly impact the ease, longevity, and scalability of the applications we build. 

The Database Dilemma: Part 1

January 29th, 2020 - by Casey Harding - Salt Lake City, Utah

One of the many things we love about the software world is how frequently new frameworks, languages, or tools will swoop into the scene and offer up new approaches to solving the problems we deal with every day. We get excited about new methods that challenge the old ways of doing things to help us do better work, faster. While it can be easy to get caught up in the hype, there are some paradigms that have impressively withstood the test of time and quite frankly, have done so for good reason.

Take databases for example. Since the early ’80s, relational databases have been the standard for structuring and connecting extensive sets of data. However, in the last decade, non-relational databases have gained avid support from the community, causing developers and data architects alike to reconsider using the former tried-and-true convention. At present, these two database types are vastly different and selecting one or the other will surely have significant impacts, for better or worse, on the applications you develop.  

Welcome to Part I of the two-part series, The Database Dilemma. In this article, we will give a brief overview for those who are “new” to the world of databases, distinguishing structured data from unstructured data and relational databases from non-relational. In Part II, we will take a deeper dive, leveraging some of our own experience working with the two paradigms. We will also give a few tips to consider when choosing the appropriate database type for your project. 

Structured vs Unstructured Data

To understand the trade-offs that come with either data paradigm, it’s important to recognize the types of data they appeal to: relational databases are great for structured data while non-relational databases tend to be better for semi/unstructured data. But what’s the difference between structured and unstructured data? 

Structured data is sometimes referred to as quantifiable data, while others will categorize it as being easily recognized and understood by computer programming languages. When we are working with structured data, we have a general sense of the nature and format of the incoming data and can thereby establish validations to keep data entries tidy, accurate, and organized with high confidence. For example, order information collected at checkout on an ecommerce website is an example of structured data. No matter the order, we can assume that a customer name, billing address, shipping address, and payment information will be retrieved and collected in a consistent, recognizable format. 

Unstructured data can be described as qualitative data, examples of which include, but are not limited to, documents, images, videos, server logs, and audio files. Data coming from multiple sources can in some cases be considered unstructured. This could be the result of each source delivering information in a unique, inconsistent format. Unstructured data tends to be less predictable than structured data, making it flexible but also difficult to impose validations on. 

Relational vs Non-Relational Databases

If you’ve ever entered information into tables on a spreadsheet, you are already somewhat familiar with how relational databases organize data. In a relational database, information is stored in columns and rows. Identifiers, referred to as primary and foreign keys, are used to establish connections between associated data housed in different tables. Prioritizing rigid consistency, relational database transactions are facilitated through SQL, the universal relational database query language, to ensure the integrity, accuracy, and durability of database transactions. This adherence to consistency and order is what makes relational databases the ideal architecture for structured data.

Non-relational (or NoSQL) databases, often referred to as document-based storage, are less like a spreadsheet and more like a file cabinet that organizes files into folders. They offer complete and total flexibility through a schemaless format, making them a godsend for unstructured or semi-structured data. At the peak of their hype, NoSQL databases boasted an inexhaustible ability to scale both horizontally and vertically, distributing computing power based on an application’s needs, a barrier that relational databases had yet to overcome. This concept of plasticity was traded for definite accuracy. The impact of this trade-off could be argued one way or the other; when dealing with gargantuan-sized data stores, the benefit of accelerated query performance could potentially outweigh an occasional transaction mistake.   

The Line is Becoming Blurred

Programmers and software engineers are always looking for opportunities to innovate, repurposing or borrowing from what’s available rather than wasting precious development time trying to “reinvent the wheel”. Over time, deciding between relational and non-relational databases might not be as difficult a choice as the overlap between the two becomes greater and there are more scenarios where either paradigm will work. For example, some non-relational databases will now allow you to employ foreign keys and indexes to sort and correlate sets of data in a way that resembles a relational database. The same goes for relational databases: by providing a JSONB field, some relational databases can offer certain aspects of the flexibility afforded by non-relational databases. Nonetheless, the current divide between the two strategies is still distinct enough that developers must consider the ramifications that will certainly follow using one paradigm in place of the other. 

In Short

Relational databases are like your Type-A personality friend: rigid and definite with minimal wiggle room. They stick to “the plan” to ensure the accuracy and credibility of database transactions. In contrast, non-relational databases are the ones with the “happy go lucky” attitude; their “go with the flow mentality” allows for flexibility when data is unstructured or semi-structured. Eventually, the two will likely inherit the benefits of the other but for the time being, deciding on one strategy or the other can have a substantial influence on the performance and maintainability of your application. For a more in-depth, comparative analysis of the two, stay tuned for Part II. 

Websites vs Web-Based Software

December 14th, 2018 - by Brett Derricott - Salt Lake City, Utah

Are any of the following true for you?

  • You’re about to hire someone to help you with a web project of some kind.
  • You work for a company with an online presence or product of any kind.
  • You’re a designer who wants to design for the web.
  • You’re a web developer.

If you said yes to any of the above, it’s important to understand the difference between a website and software that is accessible on the web.

There’s certainly a continuum, as shown below, where some websites do become more complex and some software products could be fairly simple. But the key here is to understand that there is a difference, and that the difference can in some cases be massive.

Websites vs web applications/software

To further break down the differences, let’s look at some key elements of websites vs. software that happens to be accessible via the web (also called “Web Applications”). Note that some of these bullets points aren’t hard-and-fast rules, but they should help you better understand the key differences.

A website:

  • Exists primarily to convey information.
  • Has information that is typically static and the same for all viewers.
  • May have a database but its primary purpose is to store the site’s content not the user’s data.
  • May have a CMS like WordPress or Squarespace to enable updating or maintaining the content.
  • Is often relatively inexpensive to design, build, and maintain; any complexity that exists is usually a function of the amount of content on the site or things like multiple languages, etc.

Web-Based Software (or Web Applications):

  • Often requires a fee to use (although a software product can still be free, like Facebook or Gmail).
  • Often requires a login to access.
  • Has information that is highly dynamic and changes frequently based on user input and other outside events/triggers.
  • Allows users to input, modify, remove, and otherwise interact with data.
  • Frequently involves integration of data with other systems and tools.
  • Involves algorithms, computations, calculations, reporting, transactions, etc.
  • Can be highly complex and expensive to design, build, and maintain.

Examples

Let’s look at a couple of examples to hopefully illustrate this more visually.

A Website

This is a marketing site, designed by a Web Designer, then developed by a web developer using a content management system (CMS):

An example of a marketing website.

https://www.builtforteams.com/

Note that this site is informational. It consists of a number of pages that explain what the product does, the features/benefits, and how to learn more about it or request a demo. It isn’t an actual software product. Its job is to inform, promote, and persuade. It’s also much less complex compared to the actual software product.

A Web-Based Software Product

And this is a software product, designed by a UX Designer and a UI Designer working in tandem, then developed by a team of software developers:

An example of a software product or application.

https://app.builtforteams.com/

Note that if you visit the link above, all you see of the software product is the login screen, behind which is a complex, sophisticated software application. The marketing site exists to inform prospective buyers about the software product. The software product itself is the highly complex tool that the buyer is paying to use.

Why it Matters

Here are a few reasons why it matters that you understand the differences between websites and web-based software:

Cost Expectations and Budgeting

If you’re hiring someone to help design or build something, it’s important to have an idea of the complexity of what you’re asking for so that your expectations are realistic. We frequently talk to people who are asking us to design and build a complex web application but who don’t understand why it will cost 10 or 20 times as much as the marketing site someone else made for them before.

Ability to Choose the Right Designer/Developer

Thinking that you want a website when you really want a web-based software product might lead you to hire the wrong designers and/or developers. There are a lot of designers and developers who can create a nice marketing website for you; there even tools that let you do this yourself, with varying degrees of success. There are far fewer designers and developers who can help you create an intuitive, user-friendly, robust, scalable software product.

Unfortunately a lot of web designers, or even graphic designers, don’t really understand what UX design is nor what UI design is. One evidence of this is how often designers lump the two terms together, and do it in the wrong order like this: UI/UX. When you see that on a resume or website, proceed with caution!

Hire the wrong people and you’re likely to be disappointed and waste both time and money. Many of the projects we do are for clients who had the unfortunate experience of hiring the wrong people to begin with.

Career Planning for Designers and Developers

If you’re an aspiring designer or developer it’s important that you start gaining the skills and experience necessary to succeed on the types of projects you want to do. It’s also important to sell your skills accurately, whether to a potential employer or to a client.

Summary

As mentioned before there is a spectrum or continuum from simple websites to complex web applications. Understanding the difference is beneficial to you whether you’re the one doing the work or the one hiring the people who will do it.

Accurate vs Expensive

June 18th, 2018 - by Brett Derricott - Salt Lake City, Utah

For over 15 years now we’ve been taking people’s ideas and turning them into reality. Designing and developing so many products has given us the opportunity to learn what it really takes to launch a product. That reality is often more than people expect.

When we meet with first-time entrepreneurs, it’s exciting to see the passion and energy they have for their startups. The optimism and confidence these entrepreneurs exude is a critical part of what it takes to brave the risks of starting a new venture! This optimism can, however, lead inexperienced entrepreneurs to underestimate the true cost of designing and developing a software product or app. It’s not just clients that fall victim to underestimating software projects, by the way! In our early years, we were often victims of overly-optimistic assumptions like most people are.

As soon as we have a fairly good understanding of what a potential client is hoping to create, we provide them with a rough cost and timeline estimate. When we present this estimate to a first-time entrepreneur, we almost always hear the same thing: “Wow, you guys are expensive!”

When we hear that, it’s tempting to think we need to find a way to be “cheaper”. We do want to offer the best possible service at the lowest possible price. If we can find a way to achieve a client’s goals for less money, we will always do that. We consider ourselves accountable to our clients and want to be good stewards of their money. We take this seriously and do all we can to be as lean and efficient as possible so that every client dollar goes as far as possible.

At some point, though, we can’t get much leaner. So if our estimates are frequently higher than what a potential client expects or hopes to hear, what might be the reasons for that?

  1. We’re trying to take advantage of the client and charge more than we should.
  2. We think the project is more complex than it really is, and we are therefore overestimating the cost.
  3. The project is more complex than the client thinks, and they are therefore underestimating the cost.