Structuring Complex Web Apps

Like most problems we face as individuals–or companies–we try to break each one of them down into bite-sized pieces. Solving the complexities of app structures is no different. They too are best broken down into bits we can chew on, rather than trying to consume too much at once. Knowing this, we’ve developed an internal problem-solving ideology for providing substance to these pieces, which we’ve dubbed the D.R.E.A.M. model. Let’s begin.

(D)etermine the problem/s you’re trying to solve.

First things first, you need to state the problem you’re trying to solve. All good apps focus on solving a single problem and yours should be no different. Go ahead, write it down. Look at it. Have someone else look at it. The rest of this article relies on you having a problem you’re solving, as you would otherwise have no sense of direction.

For the sake of illustration, we’re going to build the Uber of dog walking. Let’s call it Hounder. So, what’s the main problem Hounder is trying to solve for its users?

We could start by writing, “finding a dog walker.” But this definition lacks clarity and doesn’t fully encompass what we are trying to build. Thus, a better answer may be, “finding a dog walker on-demand and in real-time”. In this definition, all we did was expand on our initial conceptualization of the problem and it became infinitely more clear and enticing.

Taking it one step further, we could even define the user of this app so that it reads, “allowing dog owners to find dog walkers on-demand and in real-time”. Now that’s an app!

You’ll notice I’ve kept my answers to only a single sentence or phrase. This is absolutely intentional, as it forces you to simplify your problem as much as possible. Keeping it short and clear will ensure it continues to provide proper direction for the duration of app construction. Who knows, your definition may even be used as the attention getter on Hounder’s landing page!

So, when it comes to defining the problem your app is solving, take your time. There’s no need to rush. It’s by far the most critical step in the D.R.E.A.M. process. Just keep in mind the most important thing here is to set a solid foundation from which to build.

(R)eveal your biggest obstacle to success.

The problem you’re trying to solve comes with problems of its own. But what are those problems? And how do we begin to solve them? While there are a few things you want to consider, we’re going to focus on the overall architecture of your build. I mean, isn’t that why you’re reading this in the first place?

Important: The architecture of your app doesn’t matter if a user cannot properly use your app. In fact, your user will probably never even know what you’re using in the first place. So, hire a strong UI/UX (design) team to help you with rendering your data in a relevant fashion to said user. That group should consist of people who intimately understand the problem your app is solving, as it’s their job to make sure the user understands your vision. While we may be focusing on how your app can be built, the visual component of it is just as important and shouldn’t be discounted.

Determining the obstacles behind powering your app is best done by someone with a solid understanding of how communication happens between the user and your data storage. While the D.R.E.A.M. model attempts to create a simple formula for solving complex problems, not everyone has the capability of properly understanding the underpinnings of your problem. If you’re not best person to answer this question, that’s okay. Find someone who is. Their insight will be invaluable to you in this process.

To get your wheels turning, we can consider some of the major obstacles our example app, Hounder, may have. Three things that come to mind for us are 1) data needs to be real-time, 2) users will be fetching (reading) lots of data often, and 3) bits of data need to somehow be geolocated. Now there are definitely more than the three I just mentioned, but I’m keeping the list small for ease of understanding. Let’s call that short list good for now and move on to the next step.

(E)xplore tools that solve your largest obstacles.

Chances are you’re not the first person trying to work with real-time data. In fact, the three items we listed out previously are critical parts of many apps. You may be the first one to combine them in the way you are, but they usually aren’t individually unique. This means there’s probably a solution out there for each one–maybe even a combination–of your obstacles.

Let’s explore the idea of real-time data a little further. What makes for a good real-time app? More specifically, what databases and back-end languages excel at these tasks? Go ahead, you can use Google. There’s no shame in that. Again, people have solved this problem before and it’s a good idea to try and not reinvent the wheel.

Once again, create a list of the items you find, taking notes of any of their specific strengths and weaknesses. What SQL and NoSQL databases are out there you could use? Are there any that handle real-time data better than others? If so, what are they sacrificing to do that? Same goes for back-end programming languages. Is there one that easily manages 10k+ streams of data with ease? How mature is that language? What is it not good at? Does that language come with a framework–a predefined, programming toolset–that allows you to more easily interface with your database?

(A)nalyze those tools and your team.

Once you’ve explored the different types of languages and frameworks out there to solve your problem, you can then begin to analyze each of them for their merit. Again, writing things out and forming lists is extremely helpful.

There are three things to keep in mind at this phase. The first is, how many of your problems does each solution solve? Does it solve all of them? A few? One? A frontrunner may begin to appear sooner than you expected in this phase, but don’t jump to conclusions yet! Be patient. There are more bridges to cross.

The second item to consider is how well does this language play with other languages and/or the platforms you want to build on? Let’s say that Ruby (Ruby on Rails) came out as the frontrunner in first consideration, but you plan on building strictly a mobile app. Ruby focuses on building backend APIs (endpoints for fetching your data) and web apps. Thus, it probably shouldn’t be a first language of choice for your mobile app, unless you plan on building them out separately. Doing this can provide more flexibility, allowing you to simply build a separate web app with the same data in the future, at the cost of additional complexities and time-to-market.

Finally, you’ll want to analyze your current team–assuming you have one–with a focus on understanding their strengths and current knowledge base. It goes without saying you should probably use the things you and your team are already good at. In fact, it can be best to sacrifice the “best” tool/s for the job for the sake of developer efficiency and ability to more quickly deploy your project. But if you and your development team have the time and resources to properly learn the “best” tool/s for the job, then go for it! Otherwise we’d recommend sticking with what you know.

(M)ake a decision.

You’re nearing the finish line! You now have a grasp of what your app is, what you expect its development challenges to be, and have formed and analyzed a list of tools that can help you get this bad boy to market. So now it’s time to make a decision.

Go with your gut. This isn’t something you should ponder for long periods of time. That’s what the previous steps are for.

“But what if I’m wrong and I can’t handle my app scaling to the demands of a much larger audience a year from now?” And to that I will say, “What if it doesn’t?”

Trying to plan for what your app will look like a year from now is just a guess. Treat it as such. The best decisions you can make are the ones in the moment, as that’s when you have the most reliable information available to you. If you’re having scaling issues a year from now, that’s awesome! It means you built a product people care about and can hire people to help you solve any scaling issues you have. Your decision today doesn’t have to be a decision forever. It just needs to be one that gets the ball rolling. So get after it!