Backends 101 - PHP vs NextJS vs Python fwks

Tl;DR

Im just grasping the surface of BE development and want to see high level what each framework can do.

Because its not all about Python, but others PHP driven can do cool stuff.

+++ Cool concepts that devs talk about: pagination, ORM, database migration, endpoint…

Intro

Im mostly focused on python, despite not being a real dev.

But Ive heard a lot of people do cool things with just PHP+jquery.

Others mention a lot the power of Laravel, which uses PHP.

And FE devs, can also go into BE as they know JS, which can do more than FE.

In the conclusions, you have a table with the frameworks and how they relate to the way of rendering.

Laravel 101

Laravel is primarily a backend framework of PHP, just like Django and Flask in Python.

They all focus on handling the server-side logic, data management, and API creation for web applications.

Here’s a quick comparison to highlight their similarities and differences:

Laravel:

• Language: PHP
• Architecture: MVC (Model-View-Controller)
• Focus: Full-featured framework with a strong emphasis on developer experience and elegant syntax.
• Strengths:
  • Robust features for common web development tasks (routing, templating, database management, authentication).
  • Artisan CLI for automating repetitive tasks.
  • Large and active community with extensive resources.
• Use Cases: Building complex web applications, APIs, and backend systems.

Why is Laravel so popular?

• Ease of Use: Laravel is known for its elegant syntax and developer-friendly tools, making it easier to learn and use.
• Speed: Laravel’s built-in features and optimized structure help you develop web applications quickly.
• Scalability: Laravel is designed to handle large and complex applications.
• Maintainability: The MVC architecture and well-organized code make it easy to maintain and update your applications.

In simple words, Laravel is like a super-efficient construction crew for building amazing websites and web applications with PHP.

It takes care of the tedious tasks, provides a solid structure, and gives you the tools you need to bring your web development ideas to life.

• https://filamentphp.com/

A collection of beautiful full-stack components. The perfect starting point for your next app.

• https://github.com/filamentphp/filament

MIT | A collection of beautiful full-stack components for Laravel. The perfect starting point for your next app. Using Livewire, Alpine.js and Tailwind CSS.

Laravel is primarily a backend framework, just like Django and Flask. They all focus on handling the server-side logic, data management, and API creation for web applications.

Key takeaway:

• Laravel, Django, and Flask are all backend frameworks that handle the server-side logic of web applications.
• They differ in their programming language, architecture, and the level of built-in features they provide.
• The choice of which framework to use depends on the specific project requirements, the developer’s familiarity with the language, and the desired level of control and flexibility.

So, yes, Laravel is primarily a backend framework, similar to Django and Flask in its core purpose.

However, it distinguishes itself with its elegant syntax, strong focus on developer experience, and a rich set of features tailored for PHP-based web development.

Conclusions

If wordpress uses PHP, laravel cant be that bad.

Right? :)

Joking.

Some people are doing a lot of money with PHP+jquery.

Frameworks Comparison Table 💻

Rendering Frameworks & Approaches 🎨

This table explains the different rendering approaches (SSG, CSR, SSR, and SPA) and how Laravel, Django, and Flask typically fit into them.

Other BackEnds

Key Considerations:

• Project Requirements: The nature of your project will significantly influence your tech stack choice.
• Team Expertise: Your team’s familiarity with specific technologies is crucial.
• Scalability: Consider the stack’s ability to handle future growth.
• Community Support: A strong community provides ample resources and assistance.

1. Python, with any of its well known frameworks.

2. JS / TS can do frontend tasks, but also backend!

3. Java could do BE as well.

Even these compiled languages: C/C++ or even Go could do BE!

NextJS

Yyou can think of Next.js’s backend capabilities (like Route Handlers and Server Actions) as being functionally similar to a framework like FastAPI, but with a different focus. Both allow you to build APIs, handle server-side logic, and interact with databases.

The key difference is that FastAPI is a dedicated backend framework, while Next.js is a full-stack framework that includes powerful backend features as part of a cohesive ecosystem.

You can think that Next.js is the flask or django but in JS/TS

Next.js as a Backend

Next.js provides a “backend for frontend” pattern. This means its backend features are tightly integrated with its frontend rendering.

• Route Handlers: These let you create API endpoints to handle HTTP requests (GET, POST, etc.) and return various data types like JSON. They’re analogous to the route decorators (@app.get("/items/")) in FastAPI.
• Server Components/Actions: These allow you to write server-side code directly within your React components. This is a powerful concept that reduces client-side JavaScript and simplifies data fetching and form submissions, a capability not found in a traditional API framework like FastAPI.

FastAPI as a Backend

FastAPI is a true, standalone backend framework for Python. Its primary purpose is to build APIs.

• Focus on APIs: It’s designed specifically for creating RESTful APIs and microservices. It’s built on modern Python features and is known for its high performance.
• Automatic Docs: It automatically generates interactive API documentation (using Swagger UI and ReDoc) from your code, which is a huge advantage for developers and API consumers.
• Type Safety: It uses Python’s type hints to provide automatic data validation, serialization, and deserialization, making your API robust and less prone to errors.

In short, while both can create backends, Next.js provides backend features for a full-stack application, whereas FastAPI is an expert at just being a backend.

Just try PocketBase

If you are new to this backend stuff…

You might want to consider to go with Pocketbase as BaaS

It should simplify your start:

About fwks and APIs

Generally, backend frameworks can be made to work with all the API types.

But they are often optimized for one type more than others.

The choice of framework is often influenced by the API type you intend to build, as some frameworks have built-in support or dedicated libraries that make building a specific API type much easier.

RESTful APIs

REST is the most common API type, so almost every major backend framework has excellent support for it.

• Django & Django Rest Framework (Python): Django is a full-featured web framework, and the Django REST Framework is a powerful and flexible toolkit specifically for building RESTful APIs on top of it.
• Express.js (Node.js): A minimalist framework that is a de-facto standard for building REST APIs with Node.js. Its flexibility and middleware system make it perfect for this.
• Flask (Python): A lightweight “micro-framework” that is great for building simple REST APIs from scratch. It’s less opinionated than Django, giving you more control.
• Spring Boot (Java): A popular framework for creating production-grade, standalone, Spring-based applications. It has a strong ecosystem and excellent support for building REST APIs.
• FastAPI (Python): A modern, high-performance web framework for building APIs. It’s built on modern Python standards and is specifically designed for creating fast, simple-to-use REST APIs.

GraphQL APIs

For GraphQL, a backend framework typically requires a dedicated library or an integrated solution.

• Apollo Server (Node.js): A production-ready, open-source GraphQL server that can be integrated with frameworks like Express.js and others. It is one of the most popular choices for building GraphQL APIs.
• Graphene (Python): A library for building GraphQL APIs in Python. It’s often used with frameworks like Django and Flask.
• GraphQL.js (Node.js): This is the official reference implementation of GraphQL, but it is often used with higher-level libraries like Apollo Server.
• Absinthe (Elixir): A popular and robust GraphQL library for the Elixir language.

SOAP APIs

SOAP is a much older and more rigid protocol. Frameworks don’t “natively” support it as a core feature in the same way they do for REST, but they have libraries or extensions to handle it.

• Apache CXF & Spring Web Services (Java): Java’s enterprise environment has some of the most mature tools for SOAP, including these frameworks which simplify the creation of SOAP-based services.
• .NET Framework (C#): The .NET ecosystem has long provided strong, built-in support for building SOAP web services, especially in corporate and enterprise settings.

gRPC APIs

gRPC is a more modern, high-performance RPC framework. It’s especially popular for communication between internal microservices. The support is typically provided by official gRPC libraries for each language, which can then be used within or alongside a backend framework.

• gRPC libraries (multiple languages): gRPC provides language-specific implementations for a wide range of languages, including Python, Java, Go, C++, and Node.js. A developer would use the gRPC library within a backend application, not necessarily a separate framework.
• Go: Go is a popular language for building gRPC services due to its concurrency features and native support for compiled code.
• Node.js & Python: While you’d use the official gRPC libraries, you would often integrate them with existing server infrastructure built on frameworks like Express.js or Flask.

FAQ

The most common and contemporary API types: REST and GraphQL.

However, there are a few other significant types, each with its own approach to communication and data transfer.

These “types” typically refer to the architectural style or protocol used to build the API.

REST (Representational State Transfer)

REST is an architectural style, not a protocol. It’s the most widely used and is foundational to modern web services. REST APIs operate over HTTP and use standard HTTP methods like GET, POST, PUT, and DELETE to perform actions on “resources.”

A resource is an object or data element on the server, identified by a unique URL.

• Key Idea: REST is resource-centric. You interact with specific, named resources (e.g., /users/123, /products).
• Pros: Simple, easy to understand and implement, and highly scalable.
• Cons: Can suffer from “over-fetching” (getting more data than you need) or “under-fetching” (needing to make multiple requests to get all the data you want).

GraphQL

GraphQL is a query language for your API and a server-side runtime for executing those queries. Developed by Facebook, it provides a much more flexible and efficient way to fetch data.

• Key Idea: GraphQL is data-centric. Instead of multiple endpoints, it typically uses a single endpoint. The client sends a specific query to this endpoint, requesting exactly the data it needs.
• Pros: Avoids over- and under-fetching by giving the client complete control over the data received, leading to better performance and fewer requests. It also allows for easier API evolution without versioning.
• Cons: More complex to set up on the server side than a simple REST API. Can be less straightforward for simple use cases.

SOAP (Simple Object Access Protocol)

SOAP is an older, more rigid protocol that uses XML for its message format. It’s highly structured and has its own set of rules and standards for communication.

• Key Idea: SOAP is a protocol with strict rules. It relies on a formal contract, often described in a WSDL (Web Services Description Language) file, that defines the operations and data structures.
• Pros: Highly secure, reliable, and has built-in features for things like security (WS-Security) and transactions. Still widely used in enterprise-level applications and regulated industries like finance and healthcare.
• Cons: Verbose, complex to implement, and slower due to the larger XML payloads. It’s much less flexible than REST or GraphQL.

gRPC (gRPC Remote Procedure Call)

gRPC is an open-source framework developed by Google. It is based on the Remote Procedure Call (RPC) architectural style, where a client can directly call a function on a server as if it were a local function.

• Key Idea: gRPC is function-centric. It uses a binary format (Protocol Buffers) for data serialization, making it extremely fast and efficient, especially for communication between internal services (microservices).
• Pros: Very high performance, low latency, and efficient.
• Cons: Less human-readable than JSON-based APIs and primarily used for server-to-server communication rather than client-to-server.

Whats and endpoint?

An endpoint is the digital location where an Application Programming Interface (API) receives requests and sends responses.

Think of it as the address for a specific resource or function on a server.

Endpoints are most often URLs that define where to interact with the API.

For example, in a social media API, /users could be an endpoint to access user information.

Protected Endpoints

Protected endpoints are API endpoints that require some form of authentication and authorization before a client can access them.

This is done to prevent unauthorized access to sensitive data or functionality.

Without proper credentials, a request to a protected endpoint will be denied.

The key differences between a protected and an unprotected endpoint lie in the security measures they employ:

• Unprotected Endpoints: These are public and can be accessed by anyone without any special credentials. An example might be an endpoint to retrieve publicly available data, like a list of current news headlines.
• Protected Endpoints: These are private and are only accessible by authenticated and authorized users. To access them, a user might need to provide an API key, a token, or a username and password.

A good example is an endpoint to update a user’s profile information, which should only be accessible by the user themselves.

How Protection Works

Common methods for protecting endpoints include:

• Authentication: Verifies the identity of the client making the request.
  • API Keys: A unique string of characters assigned to a developer or application for access.
  • OAuth 2.0 / JWT (JSON Web Tokens): A framework for delegated authorization, where a user can grant a third-party application access to their information without sharing their password.
• Authorization: Determines what an authenticated client is allowed to do. For example, an authenticated user might be allowed to view their own data but not another user’s data.
• Rate Limiting: Restricts the number of requests a client can make within a specific time period to prevent abuse or denial-of-service (DoS) attacks.
• HTTPS Encryption: Ensures that all data transmitted between the client and the server is encrypted, protecting it from being intercepted.

Whats Pagination

Pagination is the process of breaking up a large dataset into smaller, more manageable “pages” to improve performance and user experience.

Instead of a single API request returning thousands of records at once, which can be slow and resource-intensive, pagination allows the client to request a specific subset of the data at a time.

This is a crucial concept for any application that handles a large amount of data, like social media feeds, e-commerce product listings, or search engine results.

PocketBase uses offset-based pagination by default, which is the most common type.

When you make a request to a collection endpoint (e.g., to get a list of posts), PocketBase returns a paginated response with a default limit of 30 items.

You can control this behavior using query parameters in your API requests:

• page: Specifies the page number you want to retrieve.
• perPage: Specifies the number of records you want per page (the limit).

For example, to get the second page with 50 items per page from a posts collection, you would make an API call like this:

GET /api/collections/posts/records?page=2&perPage=50

This makes it very easy for your frontend to build a user interface with “next” and “previous” buttons, or to display the total number of pages.

While pagination is automatic, you can also get all records in a single request by setting the perPage parameter to -1 or by using the getFullList method in the PocketBase SDKs. This is useful for smaller collections where you don’t need to worry about performance issues from a very large response.

Common Types of API Pagination

While the goal is always the same, there are several different techniques to implement pagination, each with its own advantages and disadvantages.

1. Offset-Based Pagination (or “Page-Number” Pagination)

This is the most common and straightforward method. It uses two parameters in the API request: offset (or page) and limit (or page_size).

• How it works:
  • limit: Specifies the number of items to return per page.
  • offset: Specifies the number of items to skip from the beginning of the dataset.
• Example: To get the second page of 10 items, you would make a request like GET /api/posts?offset=10&limit=10.
• Pros: Easy to implement and allows users to jump to any page number.
• Cons: Can be inefficient for very large datasets because the database still has to scan and skip all the records up to the offset, which can slow down the query. It’s also prone to issues if new data is added or removed while the user is navigating, as the total number of items and page offsets might change.

2. Cursor-Based Pagination

This method is more advanced and better suited for large, dynamic datasets.

It uses a unique, immutable identifier (a cursor) to mark the starting point for the next page of results.

• How it works:
  • The API returns a special value (the cursor) in the response, which points to the last item on the current page.
  • To get the next page, the client includes this cursor value in the next request, and the server uses it to find the next set of items.
• Example: A request might look like GET /api/posts?limit=10&cursor=eyJpZCI6MTIzNDV9, where the cursor is an opaque token provided by the server.
• Pros: Extremely efficient and highly stable. It doesn’t rely on an offset, so adding or removing data doesn’t affect the integrity of the pagination.
• Cons: More complex to implement on the backend and doesn’t allow users to “jump” to a specific page number. It’s best for applications that use a “next/previous” navigation or infinite scrolling.

How Would You Define a Database Migration?

A database migration is the process of making controlled, incremental changes to the structure (or schema) of a database.

Migrations are typically managed programmatically and allow you to:

• Add, remove, or modify tables, columns, indexes, and constraints.
• Track a history of all changes made to the database schema.
• Share and apply these changes in a repeatable and reversible way across different development, testing, and production environments.

The goal of a database migration is to ensure that a database’s structure always matches the requirements of the application it supports, without losing data.

Django’s manage.py is the tool used to manage database migrations programmatically.

It works through a series of commands.

And there are projects like QATrack, that uses it.

How Django Does It

1. Creating Migrations: You first run python manage.py makemigrations. This command inspects your Django models and creates a new migration file (a Python script) that defines the changes needed to be made to your database schema. This file doesn’t modify the database itself; it’s a blueprint for the change.

2. Applying Migrations: You then run python manage.py migrate. This command reads the migration files and applies the changes to your database. It handles the low-level SQL commands to create or alter tables, add columns, etc. It also keeps track of which migrations have been applied so it doesn’t run them again.

This approach ensures that your database schema is always in sync with your application’s models in a controlled, versioned way.

How PocketBase Does It

PocketBase also has a similar, but distinct, approach to database schema management.

PocketBase uses migrations as well, but they are handled a bit differently from Django’s.

Instead of generating Python files from models, PocketBase uses Go files that you write manually.

1. Creating Migrations: You create a new migration file using the pocketbase migrations create command. This creates a boilerplate Go file with up and down functions.
2. Writing Migrations: You then write the Go code within the up function to make schema changes (like creating a collection or adding a field) and the down function to reverse those changes. You use PocketBase’s Go API to define these changes.
3. Applying Migrations: To apply the migrations, you run your PocketBase application. The application will automatically detect and run any pending migrations.

While both Django and PocketBase manage database schema changes programmatically, Django’s model-driven migration generation is a key difference from PocketBase’s more manual, code-driven approach.

Whats an ORM?

An ORM is an Object-Relational Mapper.

It’s a programming tool that allows developers to interact with a relational database using an object-oriented paradigm, rather than writing raw SQL queries.

In simple terms, an ORM acts as a translator between your code’s objects (e.g., a User class) and the database’s tables (e.g., a users table).

Instead of writing SQL like this:

SELECT name, email FROM users WHERE id = 1;

You can write code that looks like this:

user = User.query.get(1)

Key Benefits of Using an ORM

• Productivity: You don’t have to write repetitive SQL queries. This allows you to focus on the business logic of your application.
• Database Agnostic: Most ORMs can work with different types of databases (e.g., PostgreSQL, MySQL, SQLite) with minimal code changes. If you want to switch from one database to another, you just need to change the configuration, and the ORM handles the rest.
• Security: ORMs help protect against common security vulnerabilities like SQL injection, as they automatically sanitize and escape user-provided data.
• Object-Oriented: It allows you to work with your data as objects, which aligns with modern programming practices. You can define methods on your models and use familiar object-oriented concepts.

How They Work with Frameworks

Frameworks like Django and Laravel have their own built-in ORMs.

• Django ORM: It’s tightly integrated and uses a rich API for interacting with the database. You define your data models as Python classes, and Django handles the creation of the database schema and all subsequent queries.
• Laravel ORM (Eloquent): This is a powerful ORM for PHP that uses the Active Record pattern. It provides a simple and expressive syntax for database interactions.

In frameworks like Flask and FastAPI, an ORM is not included by default. You have to choose and install one as a third-party library. The most popular choice in the Python world is SQLAlchemy, which is often called the “de-facto ORM” for these frameworks. It provides a flexible way to handle database interactions, from high-level ORM features to low-level SQL expression language.

How PB Handles ORM?

This gets to the heart of what PocketBase is and isn’t.

PocketBase does not have a traditional ORM in the same way that Django or Flask-SQLAlchemy do.

It abstracts away the need for one by providing a different kind of interface.

Here’s a breakdown of how PocketBase’s approach compares to an ORM:

The Problem an ORM Solves

An ORM solves the “impedance mismatch” between an object-oriented programming language and a relational database.

It translates complex objects and their relationships into SQL queries.

• Example (ORM): post.author.name would be translated by the ORM into a JOIN operation on the posts and users tables.

How PocketBase Handles It

PocketBase takes a fundamentally different approach. It acts as an API-first backend. You don’t interact with the database directly from your code. Instead, you interact with the PocketBase server via its REST API.

• No Direct Database Access: You don’t have a database connection and an ORM library in your client-side code (e.g., in a React or Vue frontend). Instead, you use PocketBase’s SDKs (like its JavaScript or Dart SDK) to make API calls to the server.
• API-Driven Data Management: The SDK methods are designed to be high-level and intuitive, similar to an ORM, but they are just making HTTP requests under the hood. For example:
  • pb.collection('users').getOne('user_id') is a method that makes a GET request to /api/collections/users/records/user_id.
  • pb.collection('posts').create(postData) makes a POST request to /api/collections/posts/records.
• The expand Parameter: To handle relationships (the part that ORMs are great at), PocketBase uses an expand query parameter. This allows you to “expand” a related record directly within your single API request.
  • Example (PocketBase): To get a list of posts and expand the author field, you would make an API call with ?expand=author. PocketBase handles the join on the server side and returns the related author data nested within the post object.

Is PocketBase’s System a Type of ORM?

You could argue that the PocketBase API and its SDKs collectively serve a similar purpose to an ORM.

They abstract the complexities of the underlying database, handle relationships, and provide a clean, object-like way to interact with your data.

However, it’s not a traditional ORM because:

• The logic runs on the server, not in your application. The ORM’s “translation” from objects to SQL happens on the PocketBase server itself, not in your frontend or a separate backend.

• It’s API-based. The communication is done over HTTP, not via a direct database connection.

This design choice is a key part of its appeal: it gives you the productivity benefits of an ORM without the hassle of setting up a database, writing an API, or managing connections.

You get a fully-functional backend with a clean API and powerful SDKs that feel like an ORM, all in a single file.