When you’re an independent developer you are by default a full stack engineer; whether you want to be or not. Although my day job is in a full-time innovation team, I also build solutions in my spare time — apps, websites, Alexa Skills and more.
My time (and everyone else’s) is limited, so it’s really important to consider how much time to spend on each layer, frontend and backend. These considerations will have an impact on my actual architectural and design decisions.
I always start with what’s important to users.
What’s important to users
When I build an app or website (or whatever), I always begin by writing up a list of what I think is important. It probably should go without saying — the number one item is:
What I’m building actually needs to do something that the user wants or needs
Essentially, I’m making desirability paramount. If no one needs it, no one will download it. Build it and they won’t come.
You can validate that desirability via early and iterative user feedback, and your idea should be both viable (makes financial sense) and feasible (it’s actually possible).
Once those three are out of the way, the rest of the list looks like:
- What the users care about
- That’s it
Obviously I’m being a little glib. What users care about can include a few things they may not realise they want, but that they probably would if they thought about it a bit.
Users want a great experience. That means they want:
- An easy to use frontend
- A performant frontend
- A beautiful frontend
- Security and privacy
- A frontend that’s correct / got up-to-date information
Here’s what users don’t really care about:
- A RESTful API
- A NoSQL database instead of MySQL
- Node.js instead of PHP
- Caching layers
You, as the developer, may want these things because they may help you deliver what the users want. That makes them important, but not as important as what the user wants, which is a basically a fantastic frontend experience.
What to do
Barring unlimited resources, you should spend most of your time on the frontend.
Spend as little time on the backend as you can by making it as simple as possible. Get to reliability, efficiency, accuracy, security, and get out.
What about all the amazing work backend engineers do?
If you are Netflix, with presumably entire hoards of hotshot backend engineers, you can afford to spend time (and cash) on making your backend as amazing as possible.
Most of us out on our own, however, need to keep things simple until our awesome product becomes so successful that we can afford our own hoards of hotshot backend engineers.
Only then can we say things like “let’s add another caching layer or two” or “what if we gave the ISPs our own servers to speed things up?”
My approach
If possible, I’ll go for a serverless architecture — e.g. AWS Lambda.
Who wants to spend their time configuring and maintaining a server? With Lambda, you can run code in the cloud and AWS will take care of the underlying infrastructure for you.
Learn more →This won’t work for everything (although I’ve heard arguments to the contrary), but when it does work it can significantly reduce the amount of time you need to spend during and after your project.
An example
I currently have an app that I created for my kids’ school several years ago. The backend is hosted on an AWS EC2 server, which is running PHP and connected to an AWS RDS MySQL database:
It made sense at the time, but now it’s a hassle. When I had to change some certs earlier this year I spent way too much time, that would have been better spent elsewhere, trying to remember where to change the certs on that server! Seriously … some folder in bin, maybe?
If the parents in the school knew about the server I’m fairly sure they wouldn’t care about it — I own it and I don’t want to care about it.
So, I’m replacing the whole thing with this architecture:
This looks more complicated than the old infrastructure, but it’ll be much easier to maintain and doesn’t take that long to setup. Breakdown of the different components:
Route 53 manages your DNS entry e.g. myamazingapi.com — and actually you only need this step if you want to use a custom url for your API.
API Gateway will give you a URL like:
which you can use no problem and you can leave Route 53 out of your architecture.
If you do want to use a custom URL, you’ll need to set up a “Custom Domain Name for an API in API Gateway” as detailed here, which is actually a bit of extra work that takes a while and that you may think is unnecessary in your super-simple backend.
What you will want is AWS API Gateway — Amazon’s API manager that allows you to quickly and easily setup an API, complete with version control and different “stages”, like dev, test, prod, whatever.
You can set up the standard requests you’d expect — GETs, POSTs etc. and specify which of these API request endpoints point to which AWS Lambda functions.
AWS Lambda functions
More great articles from LogRocket:
- Don't miss a moment with The Replay, a curated newsletter from LogRocket
- Learn how LogRocket's Galileo cuts through the noise to proactively resolve issues in your app
- Use React's useEffect to optimize your application's performance
- Switch between multiple versions of Node
- Discover how to animate your React app with AnimXYZ
- Explore Tauri, a new framework for building binaries
- Advisory boards aren’t just for executives. Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Written in Node.js, they are minimal and concise — each carrying out one task (basically a microservice architecture):
- one Lambda to fetch a list of the latest school news
- another to allow the post’ing of absentee forms
- another to give the latest school events
I actually like PHP but since I’ve started using Node, I haven’t gone back. Node is just too easy to setup, there’s so many great npm modules available (like mysql to connect and use a MySQL db) and, for me anyway, has resulted in less code to write.
The Lambdas themselves provide a simple way of running (and testing) code and they remove the need for servers. You can write the code in the online editor:
or you can upload a zip file of your code. I’m using Node.js but you can also write C#, Java or Python. You can also set up multiple test events in the same GUI:
And did I mention there’s no servers involved?
I’m keeping the MySQL database because it works and is easy — a few tables, easy to connect to and relatively secure. It’s hosted on AWS RDS so I don’t need to worry about maintaining MySQL etc — you just spin up an instance, then connect to your database.
Alternatives on AWS include DynamoDB, which is a NoSQL database that also doesn’t require servers and is easily accessible in your code via AWS SDKs. I’ve tried it and it’s super easy to use, I just prefer MySQL.
And that’s it. Simple.
A functioning backend, easily maintained and also relatively inexpensive (depending on your traffic and number of users). For my school app it’s a paltry amount of dollars, which is actually covered by promotional credits I earned from releasing an Alexa Skill, so it’s basically hosted for free.
Finally, it’s also worth noting that Route 53, API Gateway, the Lambdas (if you’re writing your code in-line) and the setup of the RDS db are all used online on the AWS portal, minimising the software you need to use on your machine, and allowing you be less restricted to your machines.
Alternatives
I’ve shown how to build a simple backend using AWS(mainly as I like AWS for the pricing model and the ease of use). There are plenty of other options — Microsoft’s Azure or Google’s Firebase being just two.
What’s important is that whatever you use, you keep it concise and simple, to minimise your effort now, and in the future.
All that extra time you’ll have can be used to make your frontend beautiful (and all the other things your users want)
The whole point of keeping the backend simple is to give you more time to focus on the frontend — to spend time making it beautiful, performant, easy to use, and the other user “requirements” we discussed earlier.
For tips on how to not make your app look awful, see my previous post here and for more website related design tips, see Dan Schlosser’s post here, also on the LogRocket blog.
I hope you found this useful — please comment below with any thoughts or questions and feel free to hit that little clap button! Thanks, Andy
200’s only 
Monitor failed and slow network requests in production
Deploying a Node-based web app or website is the easy part. Making sure your Node instance continues to serve resources to your app is where things get tougher. If you’re interested in ensuring requests to the backend or third party services are successful, try LogRocket. 
https://logrocket.com/signup/LogRocket is like a DVR for web and mobile apps, recording literally everything that happens while a user interacts with your app. Instead of guessing why problems happen, you can aggregate and report on problematic network requests to quickly understand the root cause.
LogRocket instruments your app to record baseline performance timings such as page load time, time to first byte, slow network requests, and also logs Redux, NgRx, and Vuex actions/state. Start monitoring for free.
An informative read. As a fresher, i gained a perspective on what is expected by employers by full stack developers. Thanks for sharing.