Basics of Fullstack Development
Working for different start-ups and also handling projects as freelancer for start-ups which are in scratch level I saw many people go for freshers for building there frontend and backend as it would not cost them so much when same thing is built by a experienced developer but they forget freshers are not acquainted with best practices and things one should know when building a backend REST API or consuming it in frontend be it any framework.
I have seen many faults and tech debts in multiple codebases which are built by freshers and it’s not there fault, they are not taught these practices, so this article will try to focus on few things what I have seen and what I have learnt work in production level projects.
Diagram how basic component of a web app works
Backend (REST API)
Starting with backend where I have worked most of my programming career. I will be focusing on Node.js but I worked on other languages also so I think some points can be used in other languages or frameworks —
- Using plain strings to save passwords - It’s easy to build things using plain strings but it’s a very bad practice specially if it’s a password. There are packages available which will hash you’re password - bcrypt is one of them and is most popular in Node.js and also available in Golang. Python provides hashlib and also you can use scrypt. If you’re using a full fledged framework then look for documentation they will provide you a hasher by default.
- Don’t send encrypted password in api - Sending a hashed password in API is bad practice even if it will take infinite amount of time decode the password using brute force still don’t do it.
- Verify users with token - It’s easy to just match the username/email or any unique id and password be it string or compare the hash string and then return whole user object but it’s not good as you might want to authorize routes to only specific user or specially users who are logged in. Also this token can be used by frontend to store in localstorage and when revisits automatically authenticate login the person. JSON Web Token (JWT) is standard for this and all major languages and frameworks provide libraries for JWT.
- Use database from very beginning of project - I have seen people using SQLite for storing data in backend and my question is why? SQLite is not meant for that. Use a proper database from very beginning and look at the benefits of using both SQL/NoSQL databases before starting using one. Here is a article from GeekforGeeks on basic differences. I know setting up a database is hard, you can go for Docker containerization of databases which will help in testing in local and also will help in learning Docker.
- Use ORMs - You might be very skilled at writing SQL queries or Mongo Queries but as these projects grow bigger and bigger writing plain SQL queries can get tedious and you can make multiple mistakes and it will also cost you time. ORMs make it easy to work with databases and also create models or schemas that should be followed when reading and writing data. ORMs also provide handy functions for SQL clauses and joins between tables or references to collections.
- Use environment variables - Use environment variables to store important things like credentials to third party APIs, API keys, secrets, database URLs and other important stuffs. Every programming language provide ways to access environment variables - In Node.js _process.env.varibablename, In Python os.environ[‘variable_name’], In Golang os.Environ(‘variable_name’). As most of the servers are running on linux it’s very easy to set environment variable be it bash shell or zsh shell (in dev environment) - export variable_name=value
- Think before - I have seen people creating api endpoints randomly named. Think before creating a API endpoint and name it wisely so that people who will be working on it later can easily understand what API they are working with also know HTTP methods.
- Know HTTP methods - Before building any API learn basic four HTTP methods and there functions. They are GET, POST, PUT and DELETE. As name suggest they do the same, GET to get a data of specific thing, POST to add or create database entry, PUT to update a specific database entry and DELETE to delete the database entry. Using POST for every operation and naming your endpoints like ‘/addpost’, ‘/getpost’, ‘/updatepost’, ‘/deletepost’ you can easily build a single endpoint ‘/post’ with all those methods. GET /post will get all post, GET /post?title=”title of a particuar post” will send all post matching the parameter, POST /post will add a post, PUT /post/:id or /post?id=”unique id of a post ” will update the particular post, DELETE /post/:id or /post?id=”unique id of a post ” will delete that particular post.
- Learn to use URL parameters - This is a continuation to last point, learn to use query string. Those are very helpful, example, when you’re sending a GET request to find a specific detail from data base like a post you can send it in query string like GET /post?title=”title of post”. Making POST request for everything is a bad practice and can increase number of endpoints you build.
- Think about pagination - Pagination is basic need in every REST API, thinking and building REST API keeping benefits in long run as data grows your app can be ready to handle large data.
- Learn basics but use frameworks - Learn basics of web developement backend in language you want but it’s my point of view that use frameworks when it comes to build production grade backend as they provide best practices inbuilt, they might be opinionated but I think sometimes opinions are good to have specially from people who are more experienced then you. Few example of frameworks like Node.js have Nest.js, Sails.js, Meteor.js, Express.js, Hapi, Koa. Python have Django and Flask, Golang have Gin, Beego, Mux, Buffalo, Java have Spring/Spring Boot.
- Use ES6 - Use ECMAScript 2015 or ES6 syntax and look for ES6 support in Node.js. If a version of V8 support it, it will be supported by Node.js for a particular version. A good place to look at it it this link.
- Use typescript - Sure typescript gives some overhead of setting up development environment but it’s good to get errors in compile time then at runtime.
Angular code splitting is very good out of box, use features provided by the framework and best thing is it’s used by Google itself for building there own products and they test on them before releasing to public.
- Use services - I have seen a common mistake that people call APIs directly from component itself. Component should only handle presentation data and delegate the access to data to services.
- Use a store when needed - Services can do most of the stuffs that state management libraries can do but when you see state is getting more complicated then it’s good to move to a state management library before it’s too late. One of community favorite ngrx/store
- Use typescript features - Typescript is awesome, it comes with some overhead of setup but if you’re using Angular then it comes out of box then why not use them like type checking at compile time, good editor supports are few among many.
- Use guards - Not taking overhead of building a else if condition is better to hand off the logic to guard that route is accessible or not. Better you have write it once and then use them in any route you want.
- Use CLI - Angular provides on of the best CLIs around you can generate anything related to Angular just using CLI be it components, services, guards etc. Also it saves time as when generating a component you get html, ts, specs and css created at one go with basic boiler plate written and component added to imports of a module.
- Use environment file - Angular provide a handy way to determine which environment it is running and will build it accordingly. There are many stages of development like dev, staging, UAT, producting and one can define different keys, base api endpoint etc in each file and then modify angular.json to check process.env and use environment file accodingly.
- Use data modeling - This is specific if you’re not using Node.js as backend, even if you’re I think it is a good practice to model data which will be sent to backend and which will be shown. Like backend can need keys to be in snake case when you follow camelcase in frontend build a class and have functions for serialization of those.
- Use Angury - Angury is Google Chrome Dev tool extension for debugging Angular apps but not for only Google Chrome, it’s now also available for Firefox. Go check it out it’s awesome.
React is another popular frontend framework that provides a developer a open platform to use libraries they want but I have seen mistakes by people.
- Axios interceptor - Axios is most popular library for making HTTP requests but very few people know axios has concept of interceptor where you can define base endpoint and other logic like adding authorization token etc. Link
- Use state management - I learned it in hard way when I was facing problem in managing large states of a application and passing props deep down component tree. Yes, setting up is hard but when application grows it pays for the initial setup.
- Differentiate between components and pages - React doesn’t provide a out of box solution for code splitting and it causes a mess if you don’t develop thinking in mind about future. If you are building a comment box build it once and use it in different which is very common following DRY principle. Have different folder like components and pages that’s how I do it.
- Use typescript - I know I am emphasising on typescript too much it’s actually good also react CLI comes with flag to bootstrap your project with typescript.
- Use React Dev tools - Similar to Augury, React also have a dev tool extension for Chrome and Firefox both.
Non framework specific
- Learn to use Dev tools - Chrome and Firefox both have very good dev tools built in. Learn to use those. Whatever you want to learn about your web app be it network request, inspect a element in DOM tree, look at your localstorage or cache, checking service worker is doing good or not they are just awesome. Also, Chrome’s dev tools are best they provide you Lighthouse, auditing your web app on best practices like page load on slow network, app is PWA ready or not, even a waterfall model what is happening in your web app.
- Think about SSR - Think about Server Side Rendering from beginning of project, it’s what I think your requirement might be different but SSR provides many benefits like faster page load, faster first render time, better SEO etc. Angular provide Angular Universal for SSR, React have different methods but most common is Next.js which is easy is setup and provides many benefits out of box, similar to Next.js, Nuxt.js is for Vue. They need there separate article.
- Use the platform - Browsers have gotten much power than they were before like there are web apis for Push, Audio, Bluetooth, IndexeDB, Storage, WebGL etc.
Frontend (Mobile Apps)
I have worked on almost all three by luck. Some for startup and some for freelance projects.
Most of the things about React Native will be same as React as component logic are same and came be share between them. Nothing much to tell about React Native from my side but one thing learn to use things like refresh control for pagination, choose routing library and ui framework keeping in mind about future of your project. Look at documentation first which will help you a lot what React Native provides out of box. Also recent shift to androidx by Google try to use new React Native or upgrade your old one. React Native provides guide for upgrade.
Building React Native project have two paths - Expo or React Native CLI. Choose one and start your project looking at requirement. If you start with Expo you can go to CLI version easily but vice-versa is not true. Once ejected you cannot go back to expo. So, choose wisely. Also many libraries depend on Native code so they might not work on Expo. Look at library documentation before using them.
Similar to what React Native does for React, Nativescript does for rest of the frameworks like Angular, Vue, Svelte, React or even no framework at all. Angular is one of the mature platform in Nativescript with rest of them are new. So carefully look at the support for rest before moving forward with one.
Ionic provides a wrapper around your web app to make is install-able as native app in your phone. It uses Cordova or recently ionic team developed Capacitor. Best thing I like about Capacitor is that you can use already a huge library of Cordova plugins in Capacitor (doc). If your app is not too large and doesn’t need extra features what native apps provide then it’s best to go with Ionic. Previously, Ionic was based on Angular, now they support all major frameworks and no framework also and there all UI components are written in Web Components so they can be used with any framework.
These are my thoughts about fullstack development and what I learned from my experience. Also there are few thing like deployment which are handled by developers itself in startups need also to be thought. There are many options between AWS, GCP, Azure, Openshift, Heroku etc. Which needs there own article.
This article was originally published on Medium