DEV Community: Jeremy Panjaitan

Backend Framework-Independent Concepts: A Guide for Modern Developers

Jeremy Panjaitan — Wed, 28 May 2025 15:26:02 +0000

In the world of software development, backend engineers often find themselves switching between frameworks - NestJS, Express, Spring Boot, Django, and more. However, beyond framework-specific syntax and tooling, there exists a set of universal backend principles that every backend developer should master. These principles are foundational and apply regardless of the language or stack you are using.
In this article, we'll explore the most important backend framework-independent concepts that help ensure scalable, maintainable, and secure systems.

Layered Architecture

A good backend system separates concerns using a layered structure. Typical layers include :

Controller Layer: Handles HTTP requests and responses.
Service Layer: Contains business logic and core processing.
Repository/Data Access Layer: Interacts with the database.

This structure promotes modularity, reusability, and testability.

RESTful API Design

REST (Representational State Transfer) is the most common architectural style for designing APIs. Key principles include :

Using HTTP verbs correctly (GET, POST, PUT, DELETE).
Designing intuitive URIs (e.g.,/users/123)
Returning meaningful HTTP status codes (200 OK, 400 Bad Request, 404 Not Found, etc.)

Resources :

Authentication & Authorization

Security is a non-negotiable part of any backend system :

Authentication verifies who the user is (e.g, JWT, OAuth, API Keys).
Authorization defines what the authenticated user is allowed to do (e.g., Role-Based Access Control).

Proper implementation ensures that sensitive data and operations are protected.

Error Handling & Logging

Consistent error handling improves user experience and developer productivity :

Centralized error handling logic to avoid repetition.
Standardized error response formats (e.g., error code and messages).
Structured loggin (JSON logs, correlation IDs) for observability and debugging. Tools like Winston, Morgan, or Logback can help with log management.

Environment Configuration

A robust system externalizes configuration using environment variables. Benefits include :

Easy switch between development, staging, and production
Secrets and credentials are not hardcoded in the codebase. Tools like dotenv (.env) files help manage environment-specific settings.

Database Abstraction

Direct SQL is powerful but can be error-prone and hard to maintain. Using an ORM or query builder provides :

Reusable models and relations
Easier migrations
Transaction support

Caching

Caching can significantly improve performance

Use tools like Redis or Memcached.
Decide between strategies like TTL (time to live), LRU (least recently used), and manual invalidation. Just be careful: caching adds complexity and must be invalidated correctly.

Background Jobs & Scheduled Tasks

Not every task belongs in a request-response cycle.

Use job queues (e.g., Bull, Celery) for heavy processing.
Decide between strategies like TTL (time to live), LRU (last recently used), and manual invalidation. Just be careful: caching adds complexity and must be invalidated correctly.

Dependency Injection (DI)

DI makes your code more modular and testable :

Don't instantiate dependencies directly.
Inject them from outside (via constructor, function args, or DI container). This principle leads to decoupled code that's easier to mock and test.

API Documentation

A well-documented API is a joy to work with :

Use Swagger/OpenAPI for interactive docs.
Maintain a Postman collection for collaborating with frontend or third parties. Documentation isn't optional - it's part of your API.

Testing

You can't ship quality software without tests:

Unit tests for individual functions and services
Integration tests for multi-component logic
End-to-end tests for real-world scenarios Investing in tests pays off in confidence and velocity.

Security Best Practices

Security must be baked in from the start

Always validate and sanitize inputs
Avoid common attacks: SQL Injection, XSS, CSRF
Use HTTPS, rate limiting, and secure headers. Good security protects your users and your reputation.

CI/CD Automation

Continuous Integration/Deployment keeps teams moving fast:

Automate tests, linting, and builds.
Use pipelines to deploy with confidence.
Include rollback strategies in case things go wrong.

Observability

Monitoring is more than just logging :

Logs: For tracing actions and debugging.
Metrics: For performance (CPU, memory, latency).
Tracing: For understanding complex, multi-service flows.

Use tools like Datadog, Prometheus, and Grafana to gain visibility into your systems.

Scalability

As your system grows, so should your architecture :

Design stateless services that can scale horizontally.
Use load balancers and autoscaling.
Think about sharding, partitioning, and message queues when necessary. Scalability is a mindset, not just a techincal feature.

Final Thoughts

Frameworks come and go, but these concepts form the foundation of backend engineering. Mastering them will help you write better code, build more robust systems, and collaborate more effectively with other developers.

How prepared statement prevent SQL Injection ?

Jeremy Panjaitan — Sun, 09 Jan 2022 12:47:00 +0000

Motivation

Have you ever heard about sql injection ?. For the nutshell sql injection performed by user/client by injecting additional sql query to gain access to your system that you built. consider you have a database table with 2 field username and password to authenticate user to login into you system. You also provide a backend to query the user's data to database and then you construct string query like this.

sql := fmt.Sprintf("SELECT * FROM users WHERE username = '%s' AND password = '%s'", username, password)

with this query, the system will be hacked by an irresponsible person.

How to prevent using prepared statement ?

let say that an irresponsible user send username = user' or '1' = '1 and password = pass' or '1' = '1. The result of concatenation of that sql query will be.

SELECT * FROM users WHERE username = 'user' or '1' = '1' AND password = 'pass' or '1' = '1'"

What ever username and password that user will be passed to backend always makes that query resulting success.
So to avoid this, we need to use prepared statement.

stmt, err := db.Prepare(`SELECT * FROM users WHERE username=? AND password=?`)
row = stmt.QueryRow(username, password)

Prepared statement will treat the username and password input always as an argument not as a query statement. So the user password is literally pass' or '1' = '1. Prepared statement will pre compiled the string query with the placeholder. Then the argument will be placed later on when you are using that precompiled prepared statement.

Is anybody has project ideas for realtime app ?

Jeremy Panjaitan — Wed, 17 Mar 2021 04:58:25 +0000

Currently studying django channels. It is a library that enable django for realtime app. Any ideas for project realtime app ?

SSR vs CSR

Jeremy Panjaitan — Wed, 23 Dec 2020 02:16:45 +0000

SSR vs CSR

in this article, I want to share with you the difference between server-side rendering(SSR) and client-side rendering(CSR). knowing the difference between those two things is very important, especially when you are developing on the web. first of all, I will explain the definition of SSR and CSR, then I will cover the difference between them, and for the last, what kind of circumstances are suitable for each.

what is SSR ?

SSR stands for server-side rendering. it is the ability of a web application to render the web page on the server instead of rendering it in the browser. when the page arrived on the client-side, it is fully rendered. it is because the server-side has fully rendered the page before it was sent by the server to the client. when the request is received on the server-side, it will compile everything, if the content of the page needed data from the database, the server will do that, then render the data into the fully rendered page and then send it to the client as the response. now, what if the client navigates to a different route? every time the client navigates to a different route, the server will do the work all over again.

what is CSR ?

CSR stands for client-side rendering. overall, CSR is the opposite of SSR. If the SSR renders the page on the server-side, CSR renders the page on the client-side. when the request is received on the server, it will not render the page, instead, the server will send a single page that will be the skeleton of the page to the client. the server sends the page along with the javascript file. later, the js will turn the page into a fully rendered page. so where is the content? what if the page needs to take data from the database? Then, the api comes in. the client will make a request to the api to take the data and then render it to the page. Lastly, what if the client navigates to a different route? do the server will send the page again ? the server will not send the page again, instead, the client will re-render the page according to the route that client requested. so the page that is used, is always the same page as the first request.

the difference

the main difference between CSR and SSR is where the page is rendered. SSR renders the page on the server-side and CSR renders the page on the client-side. Client-side manages the routing dynamically without refreshing the page every time the client requests a different route.

use SSR

if SEO is your priority, typically when you are building a blog site and you want everyone who searching on google go to your website, then SSR is your choice.
if your website needs a faster initial loading.
if the content of your website doesn't need much user interaction.

use CSR

when SEO is not your priority
if your site has rich interactions
if you are building a web application

# Asynchronous vs Synchronous in javascript

Jeremy Panjaitan — Thu, 10 Dec 2020 10:53:42 +0000

synchronous and asynchronous are very confusing concepts in javascript programming language especially for the beginners. for me it will took very long time to understand those two concepts. in this article i will share with you the difference between asynchronous and synchronous in javascript. is it one better than the other ?

what is synchronous ?

synchronous means that if you execute some code, it will be executed the code line by line. javascript uses single threaded and also uses synchronous execution model. single thread means that one statement is being executed at a time. so in javascript one thing is happening at a time. take a look of this code

console.log("first statement")
console.log("second statement")
console.log("third statement")

The result will be :

first statement 
second statement 
third statement

as we can see, the statement was executed line by line.

what is asynchronous ?

asynchronous is the opposite of synchronous. Each statement will not wait for the previous statement to finish before executing the next statement. there are many examples of asynchronous such as promises, async/await, setTimeout function, and setInterval function. but in this article i will stick to the basic example. just for the basic understanding. consider these lines of code

setTimeout(function () { console.log("foo") }, 4000)
console.log("bar")

guess which console.log will be executed first...

bar
//wait for 4 seconds
foo

as you can see the second statement was executed first. in this example setTimeout is non-blocking, because it didn't block the execution of the second statement.

now, which one is better ? does one of them is better compare to the other ?

actually there is none of them is better compare to the other. each of them suited for specific use cases. generally in web development asynchronous is used when making a request to the api, when doing a task that will be finished later. synchronous is used when we need to execute the code sequently

that's all for this article. thank you for reading to my first article. leave a comment if i have wrong understanding about this concept. thank you