Technology Stacks

Front End

  • We’ve talked about HTML, CSS, and JavaScript
  • These allow us to build some webpages
  • However, what if there’s a common task people want to code?
  • We have a way to distribute that to other with something called libraries and frameworks
    • Some common frameworks for JavaScript are Angular, Ember, and React
  • The different choices between frameworks are often based on varying factors:
    • How familiar are we with a given framework?
    • What parts of the framework’s stylistic conventions do we like
    • How does the framework mesh with our project?
    • Do we have a high cost to learning that might slow down our work?
    • How well-designed is the framework?
      • Are the optimizations for having more customers in the future?
    • The choices and tradeoffs are almost endless, but it’s dynamic
    • In fact, we do not necessarily need to use the most popular framework in order to minimize regret

Back End

  • Here too are many choices - Java, Go, .NET, PHP, Python, Ruby, Scala, Django, Flask, Laravel, Node.js, Rails
  • Within these choices are several frameworks and libraries
  • These exist to make common tasks or items accessible
    • For example, maybe there’s a common functionality (authenticating users) or an asset (a menu design) that people like
    • These libraries and frameworks can make this sort of thing easily accessible across coders and engineers
  • The choices here can be informed by what engineers know, what the technology being used supports, and so on
  • Some of these frameworks and languages were designed with specific problems in mind
  • Many of these options are evolving rapidly, and so different versions within a choice have varying tradeoffs
  • And so many varying reasons for use
  • Some of the “right questions” that can come up when deciding a framework or language to use involve:
    • What are people able to learn - will new hires need to be experts on an obscure language to work here?
    • Do the current engineers have extensive background in the technology?
    • Does the technology solve a current problem and leave room to solve future ones as they arise?
    • And these are just a few of the reasons to consider when looking at a language or framework to use

Databases

  • These store data from users
  • Again, many choices - SQL, MariaDB, MongoDB, NoSQL, HBase
  • And again, many of these choices are informed by:
    • Past experience
    • Financial cost
    • Infrastructure support

SQL (and NoSQL) - Structured Query Language (And Not)

  • CRUD
    • Create
    • Read
    • Update
    • Delete
  • In SQL, there are four main commands or keywords that line up well with this acronym
    • Create
    • Select
    • Update
    • Delete
  • In both cases, these are all operations done on and with data
  • Specifically, user data
  • What is a SQL (or more generally, relational) database?
    • Generally, a piece of software that allows you to lay out data, with relationships between the data
    • Think back to the last time you used a table of data, maybe in a context like Excel
      • Data is not thrown around at random
      • Instead, we have rows and columns, and even different sheets of data to indicate varying meanings (dates, names, emails, etc)
  • A benefit to using software like SQL, the operations on data are meant to be quick
  • We don’t want to search a database by “brute force” or searching through the whole thing
  • We, being humans, can help the databases store data properly
    • For example, we often know what kind or type of data will be going into a given database
      • Integers, characters (char), etc
      • Some of the specific data types that are commonly used are:
        • CHAR, VARCHAR
        • SMALLINT, INTEGER, BIGINT
        • FLOAT, REAL, DOUBLE PRECISION, DECIMAL
        • DATE, TIME, TIMESTAMP
        • etc.
  • The more specific we can be when creating a database, the more helpful it can be in storing and retrieving data
  • It might take us some time to think through how we’re going to be storing thing
  • But this cost will save us time that will continue to save us time over possibly millions of entries
  • If we over-allocate space for things, then we’re being wasteful, so it’s necessary to know or anticipate how big our data will be
  • A real problem in computer languages is how to represent floating-point numbers, or numbers that aren’t quite integers
  • We only have a physical amount of space, but an infinite number of numbers
  • We do have the ability to be more precise, with different datatypes, but at the cost of potentially space
  • Within a relational database, we have other options too:
    • PRIMARY KEY, FOREIGN KEY, UNIQUE
    • If we know that we will have a unique identifier for each row, we can call that a PRIMARY KEY, and make it easier to find
    • If we don’t want any data to be duplicated, we could tell the database to keep a certain COLUMN UNIQUE - emails, phone numbers, usernames, etc
  • No matter how we get the data, as by HTML form, it will likely end up stored in a database

Storing Information

  • Imagine someone, Zamyla, bought a single widget for $9.99
  • And another customer, Robert Bowden, bought 2 widgets at the same address, for $19.98
  • Maybe we should have columns - for Product, Quantity, Name, Street, City, State, Zip Code, Country, and Total
  • What data type should each of these columns have?
    • Product -> If we say CHAR(8), this cannot contain any product of more than 8 characters
      • If we use CHAR(16), then we’re wasting a good number of spaces
      • If we use VARCHAR(16), then it makes it more difficult to search through this column
      • When we’re talking about millions of entries, this will add up
    • Quantity - likely going to be INTEGER
    • Name - We aren’t sure how big someone’s name will be, but maybe VARCHAR(128)
    • And same for City and Street
    • For State, at least in the US, we know that we can optimize this via the two letter code, CHAR(2)
    • Zip Code may beg for some design decision making - do we want to use an INTEGER, a CHAR?
    • For country, we have some design choices to take into account, depending on who we want to sell to, and how their country codes work
      • Likely some form of CHAR
    • For Total, we don’t want to be accidentally creating or losing pennies with transactions, so maybe we want the accuracy of DECIMAL
  • As we get more and more transactions, and the same people order multiple times, we’ll end up with many Robert and Zamyla entries
  • Now we could create a new table for customers, Customers
    • Within this table, we could store a customer ID, their name, and their address
    • Now, storing purchases in our first table is easier
      • We only need to store the ID of the customer and their corresponding purchase
  • We can go even further and create a table for storing information about each of our products
    • This way each product has an ID, along with all of the information stored in it
  • Our original table for purchases is now what we call normalized, or made more optimal for being used as a database
  • In our Orders table, the customer and product ID’s are foreign keys
    • They uniquely identify customers and products in their respective tables

NoSQL

  • Our previous work was pretty hefty - a lot of thinking and time
  • That work will pay off over time, but there is another paradigm for databases
  • This idea has objects and doesn’t use tables, columns, and rows
  • A popular NoSQL database is MongoDB - which stores things as key-value pairs
  • Often, the data objects are stored such that within a purchase object there is a customer object, and inside that is probably information about that customer

Mobile

  • When designing for mobile devices, Android generally uses Java, and iPhones generally use Objective-C or Swift
  • There is plenty of room to make design decisions here though
    • For example, you could design an application to use an embedded web browser and design the app with JavaScript and HTML and CSS
  • If we want to develop in an intermediate language, like JavaScript and then convert to Java or Swift, there’s a cost
  • Maybe we want to only target one customer base, and so only develop in Swift or Java (Apple or Android)
  • But if we want to develop for both, there’s a cost
    • We either need a developer who is comfortable in both languages, or two developers
    • In both cases there’s an increased cost: financially, talent-wise, and so on

Summary

  • These technology stacks are really just lists of options
  • When navigating this world, it’s important to have discussions about the varying tradeoffs to using any one technology
  • From there, we can make informed decisions about how we want to move forward