Introduction

When I first consider developing a new application to solve a problem, I’ll mentally model how it works.

What does the user experience look like? How do I convey the work flow in a way that is immediately apparent to someone who has never seen this before?

Once I have the application’s UX envisioned, I begin modeling the work flow. Every app has three core pieces - the UI, business logic & data source(s).

These three pieces function to take some action in the user interface, execute business logic on it, using, producing or storing outcomes in the data source(s). That’s it. Every application across the globe decomposes to these three fundamentals.

Once you recognize this, it becomes a lot easier to rapidly model something new. This is what i call Rapid Application Modeling.

Where do I begin?

UX

I always begin with a basic UX holder - a page that is generally shaped like the application I ‘saw’ in my mind’s eye while first imagining it. This allows me to wire up user controls quickly because the visible interface components already exist.

Over the past couple years I’ve used tailwind as my CSS framework. That choice led me to discover numerous tailwind templates or blocks that implement the shape I want. For example, if my app needs a dashboard with a stacked menu in the left frame, there are several from which I can choose. Many of these are licensed for free use, some are paid while others utilize a subscription model. Pay attention to the license and use these templates only as the authors allow.

Once the front end has been established, you need to create some business logic in your backend server.

App Server

I have used node.js & plain javascript for the past ten years to create my application servers. Using a single language for both frontend rendering & logic as well as backend processing is a huge timesaver for me. I don’t have to switch between sets of rules, syntax or even coding styles when I move between the two contexts.

If you use another language for your backend, my server tips will only generally apply.

I begin by pulling out the code block for my core server, one I’ve used repeatedly on multiple projects. It’s based on Express, works well and allows me to immediately begin implementing APIs. I start with a simple health check.

If you use Express the way I do, you’ll have an app object that is an instance of express’ http server. You may have an https instance as well with a secure port listening. If so, you’ll need to setup your SSL certificate. That’s pretty straightforward these days using Let’s Encrypt. If you’re modeling on an EC2 instance instead of locally on your Mac or Windows box, you can use AWS Certificate Manager. This will require you to setup a resolvable name using Route 53.

Just use HTTP

That’s ultimately throwaway work. If I deploy this into a production environment, it will be behind a load balancer with a certificate attached to it, terminating SSL connections & forwarding http traffic to instances or other resources off the public network. I don’t usually implement SSL when I’m modeling.

Let’s stick with http for now. The whole point of rapid modeling is to determine whether the idea works. We don’t need https and SSL certificates for that.

APIs

The health check is the simplest API you can implement. When complete, you can use it to test connectivity between your front and backend, model some query parameter handling and use it as a base for the next set of APIs.

Database Connectivity & Login

The data source you connect to your application is probably a database under your control. This isn’t meant to be a Captain Obvious statement - you could easily create an entire application using the responses from publicly available APIs like weather services as your data sources. For our purposes, we’re going to use a database that we create. The first API we’ll implement after our health check is a login convenience method.

Summary

I’ll go into more detail on each of these steps in future posts, but for now we have these high-level tasks:

• Implement the app server
• Put a couple HTML pages in the server’s public folder
• Write a health check API endpoint
• Create the database with an accounts table
• Make a connection to the database in your server
• Write the login method (which is just another API) that uses that connection
• Test for CRUD using the login API from a form in your frontend web page

You now have a functional application. It doesn’t do much, but the basics are covered.

Check back for detailed discussions on each of these steps in the coming days.