Building Consumer Apps Part 1: Cooking Up A Great App

Hello everyone! I’m new to Medium, but I wanted to start by sharing some of my ideas about apps. I’ve been working toward a career as an app developer for a few years now, and I just completed my first stint at a startup called Wiblits — which failed (insert string of negative emojis here). However, it was a great learning experience about what does and doesn’t work when it comes to apps.
There are thousands of apps out there, so a lot of people feel like all the good apps have already been made. But there are also a lot of terrible apps out there. So in the 10 years apps have been around, why is it that we could only manage to come up with a handful of life-changing apps? (I’m talking Uber, Instagram, Snapchat, Spotify, etc.) I think part of the problem is that people don’t know how to turn their good ideas into good apps. Users nowadays expect apps to be perfect, and just the slightest slip will probably result in an instant delete. The goal of this series is to provide some options about the technology and process behind creating a great app that performs well and provides a positive user experience.
Every good app starts with a good idea, so I’m gonna need an idea to work with in order to write this post. Since I’ve been out of work, I’ve labeled myself as a “househusband” since my wife is carrying the torch right in terms of making money now while I stay at home and cook (thanks dear!). In that time I came up with an idea for a recipe app. It’s not very original, but I was surprised that even big names like Food Network haven’t developed any cool web apps to store and share recipes — it’s all old-school static web pages.
So for the purposes of this series, let’s talk about how to build a sweet web app called CookMe that allows you to create and view all your favorite recipes. Yum!
Now that we’ve decided what we want to build, I’m going to list the technologies that have worked for me and for the team at Wiblits. There are hundreds of options out there, but this combo has worked for any piece of consumer software I’ve been able to dream up. I’ll provide some reasons why this stack works so well along the way (#1: they’re all free and open source).
The Database: PostgreSQL
When I build an app I like to start with the database. We’re going to be setting up a REST API with endpoints that will query the database, so I like having everything squared away on the database side before I set up my web server.
PostgreSQL is a tried and true database technology that is supported by Amazon Web Services and other platforms. I don’t really have any super convincing reason why you should use this as opposed to a NoSQL database, but coming from a business background I already knew some SQL, and there are a few programs like pgAdmin and Postico that make it really easy to visualize and set up the database. As a visual kind of person I like that.
In order to get PostgreSQL you can use Homebrew (if you’re on a Mac), otherwise there are installers for every platform that will do everything for you. Then you need to make sure you can connect to your local computer’s database. I’m not going to go into detail on that, but being able to run everything in the stack locally will save you a lot of time and effort in the long run when it comes to building apps.
Since it’s SQL-based, we’re going to have to set up tables and relate them using primary and foreign keys. If you don’t know SQL and this makes zero sense I’m sorry! But it probably wouldn’t hurt to learn it since it’s everywhere in both the tech and business worlds.
For our cooking app, we have to decide what information we’re gonna want to store. We’ll need a users table if we want people to have individual accounts with their favorite recipes that they can access from different devices. For the actual food-related stuff, we might have three tables called recipes, ingredients, and directions, where each recipe has a set of ingredients and directions, and each row in the ingredient and direction tables points back to a specific recipe.
We’ll also need to set up constraints so the database doesn’t get out of whack. For example, we might add a constraint to make each e-mail address be unique, so the app would eventually throw an error if anybody tries to make a new account with the same e-mail.
It takes time to come up with a good database design, but again, in this post I’m trying to explain the overall process, so I’m not gonna dive into it.
The Server: Golang
Golang (“Go”) was developed at Google in 2007, and has since gotten kind of a cult following. A lot of fans call it the “web server of the future.” I never would have known about it if it wasn’t for our baller CTO and lead engineer at Wiblits, Conrad Kurth. But since I’ve started to use it myself, I can tell you it’s pretty great. It performs really well and the language is pretty easy to pick up. One of the main benefits is its ability to handle lots of concurrent operations. So for consumer apps that would potentially scale to millions of users, with thousands of requests being made at the same time, it seems like a pretty good choice. And it’s not like it’s some hipster language that only a few cool kids are using. Uber has an entire site dedicated to Go development, and it was listed at #12 on the most popular languages of 2017 according to Stackify.
The gist of it is setting up packages and data types that correspond to the data we’ll need for our app. You can easily reuse packages across apps (for example, if you make a package for users that handles creating, editing, and getting info for a user account, blocking/reporting another user, etc.).
When the Go server runs, it uses a router that registers all the endpoints used throughout the app and will be responsible for handling all the network requests. (If you are new to development, an endpoint is just a server request that returns whatever data you want, such as a list of all your recipes.) Each individual endpoint will ask the database for some information and then package that information up into JSON objects, which makes it easy for web and mobile clients to work with.
Once the server is built it can be deployed to a remote server using AWS, Heroku, or something similar. Heroku has some free options that only cost money after a certain amount of traffic, which is cool for development. AWS also has a free tier and low-cost options when you’re just building stuff and don’t need production-level servers. Both are well-documented and have great tutorials, so you can get your apps deployed and start showing them off to your friends and family in no time!
The Web App: React & node.js
React has gained a lot of traction over the last couple years for both web and mobile. A few reasons why are: 1) It’s JavaScript-based, which has a gigantic community, 2) It’s built and maintained by Facebook, which is continuing to put resources behind it, 3) it functions like an OOP language so you can reuse “components” and libraries across apps, 4) if you plan to have a mobile client, using it in conjunction with React Native it can greatly reduce the amount of code needed for your project, and 5) you can easily build responsive web apps that look and feel cleaner than a nun after a spa day.
React uses node.js and npm on the server side, so you’ll need to get those installed before you can develop with React. The server part of the web app isn’t too much work to get going, but if you haven’t used it before it might take a minute or two to figure out. Check out Create React App for easy setup.
Mobile: Hybrid Android/iOS & React Native
React Native will never feel 100% like an app that’s entirely native, and since it’s not maintained by Google or Apple there are certain risks (like Facebook abandoning React altogether, which isn’t very likely but you never know). But in a lot of cases it can get the job done, and most code written in React Native can be shared across iOS and Android. Since we’ll build the web client in React, we can easily repurpose things to work with React Native. And there are some cool libraries now, such as one recently built by AirBnb, that allow you to seamlessly navigate between React Native and native screens. Awesome!
All right, there you have it. A working tech stack for a consumer app that includes a database, server, web client/server, and mobile.
What do you think? What do you like or dislike about these technologies? Are REST APIs going to be dead soon with things like GraphQL on the rise? Is Xamarin better than React for cross-platform development?
In Part 2 of this series, I’ll be talking about workflow and the process for actually building features in the app. Stay tuned!