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.
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:
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:
Here’s what users don’t really care about:
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.
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.
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?”
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.
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.
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
Written in Node.js, they are minimal and concise — each carrying out one task (basically a microservice architecture):
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.
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.
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
Monitor failed and slow network requests in productionDeploying 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.
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.
Hey there, want to help make our blog better?
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.
Sign up now
Learn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Learn more →
One Reply to "Maximizing business value as a full stack developer means a beautiful frontend and a simple backend"
An informative read. As a fresher, i gained a perspective on what is expected by employers by full stack developers. Thanks for sharing.