Features

During the planning phase, I defined the basic features that are needed to use the tool properly.

• Authentication
  • Login
  • Register
  • Password reset
• Profile Management Dashboard
  • Create and manage a profile
  • Edit profile content
  • Customize the design of the profile page
  • Use templates
• Analytics
  • Visitors
  • Page views
  • Bounce rate
  • Session duration
• Public Profile Page
  • A public page that shows the profile and links

Tech

For the technical foundation of the project, I chose the following technologies:

• Nuxt 4
• Nuxt UI
• Supabase (self-hosted, PostgreSQL)
• Tailwind CSS
• Plausible (self-hosted, used for analytics)

Implementation Process

Because the total project time was limited to 100 hours, I had to focus strongly on the most important parts. Since this project allows users to design their own profile pages, I skipped most of the visual design work and focused on functionality first.

Database Structure

I started by planning the data structure. I used the authentication system and tables provided by Supabase and added my own tables on top of that.

A profiles table that stores all profile-related content except the links.
This includes fields like display_name, bio, location, and a JSON field that contains all theme settings. This makes it easy to switch or extend themes later.

A profile_links table that stores all links belonging to a profile.
Each link has attributes like title, url, and is_highlighted.

Security and Access Control

The frontend connects directly to the Supabase backend using an anon key and the project URL.
To make sure users can only read or edit data they are allowed to access, I used Row Level Security (RLS).

Some examples:

• Everyone can read public profiles that are not in draft mode.
• Profiles and profile links can only be edited by their owner.

Frontend and Dashboard

After setting up the backend, I started working on the frontend.
The authentication system was very easy to implement because Supabase already provides most of the required functionality. Email verification is also included and is sent via a Gmail account.

For the dashboard, I had a rough concept in mind from the beginning.
Using the Nuxt UI dashboard system made the setup much easier, since it already provides layouts with sidebars, panels, and navigation.

The dashboard is structured around a sidebar with the following sections:

• Content and Design Editor
• Templates
• Analytics
• Settings

In the content and design editor, users can change almost all profile and link attributes and see the result live next to the editor.
All changes are saved as a draft first. Once the user saves and the profile is set to public, the changes go live.

The profile design is based on theme JSON files. There is a list of predefined themes that can be selected in the dashboard. Each theme JSON contains all styling information, such as colors and layout settings. By swapping the active theme JSON, the visual appearance of the profile can be changed dynamically without affecting the profile content.

Analytics

For analytics, I chose Plausible because it can be self-hosted and is more privacy-friendly than alternatives like Google Analytics.
A big advantage is that no cookie banner is required.

The setup was simpler than expected. I deployed Plausible using Docker on my server, created a project for the site, and then connected it to the Nuxt app using a Nuxt plugin. Overall, this part took much less time than I originally planned.

The post LibT Project – 1. Semester appeared first on Mobile USTP MKL.

Cloud databases are now a central component of modern web and mobile applications. Instead of installing, maintaining, and scaling databases themselves, developers can rely on services provided via cloud platforms. The providers then take over tasks such as infrastructure management, updates, backups, and high availability. For companies, this means less operational effort and a stronger focus on the actual application.

In web and mobile development, NoSQL databases in particular have become established in recent years alongside relational databases. The main reason for this lies in their flexible data models and good horizontal scalability. While relational databases rely heavily on fixed schemas, NoSQL databases allow a more flexible data structure. This is especially helpful when data models change frequently or when different data types need to be stored.

This blog post focuses on MongoDB Atlas as an example of a modern NoSQL cloud database. The goal is to classify the service from a technical perspective, highlight its strengths and limitations, and compare it with other widely used NoSQL database services. 

What is MongoDB Atlas?

MongoDB Atlas is a fully managed cloud database service based on the MongoDB database. The provider is the same company, MongoDB Inc.

Atlas provides MongoDB clusters as a service and supports various cloud platforms such as Amazon Web Services (AWS), Google Cloud Platform, and Microsoft Azure. Users can choose both the cloud provider and the region in which their database is hosted. In addition, MongoDB Atlas also supports multi region or global cluster setups when data needs to be distributed across multiple geographic locations.

Core features include automatic scaling, integrated backups, monitoring, and security mechanisms. Scaling can be performed both vertically and horizontally without manual intervention in the infrastructure, directly via the web interface. Backups are created automatically and can be restored at any time.

As the name suggests, Atlas uses the document oriented MongoDB data model. Data is stored as BSON documents, which are very similar to JSON and allow nested structures. MongoDB supports ACID compliant transactions (Atomicity, Consistency, Isolation, Durability) across multiple documents, enabling the implementation of more complex business logic.

For getting started, Atlas offers a free tier cluster. This is suitable for learning purposes, prototypes, and small applications. Higher performance clusters are billed based on usage.

Technical foundation

Document oriented data model

Unlike relational databases, MongoDB stores data in documents that do not require a fixed table structure. Each document can contain different fields. This schema flexibility makes it easier to adapt data models over the course of development.

For applications with dynamic requirements, such as APIs, this is a practical advantage. At the same time, MongoDB also supports optional schema validation to enforce basic structures.

Scaling and sharding

MongoDB Atlas supports horizontal scaling through sharding. In this process, data is distributed across multiple nodes, known as shards. Atlas handles replication, load distribution, and balancing automatically.

As the number of users grows or data volumes increase, the cluster can be scaled easily without downtime. Another major advantage is multi region setups, which make it possible to store data physically closer to users and thus reduce latency. However, multi region setups only provide real added value if the backend or connected services are also distributed across multiple regions and are not operated exclusively from a single central data center.

Performance, monitoring, and operations

Atlas provides integrated monitoring features. These include metrics for utilization, query performance, and resource usage. Slow queries can be analyzed and subsequently optimized.

There are also alerting features that automatically send notifications in the event of unusual behavior or errors. This further helps to keep the operational effort for development teams low.

Advanced Atlas services

In addition to the classic database, MongoDB Atlas also offers further services. Some of the most important ones are listed briefly below.

• Atlas Search is an integrated full text search based on Apache Lucene, which removes the need to develop a separate search system.
• Atlas Vector Search enables similarity searches based on vectors, for example for semantic search or AI related use cases.
• Atlas Triggers allow the execution of serverless functions in response to database events such as inserts or updates.
• Atlas App Services provide features such as authentication, serverless functions, device synchronization, and offline synchronization.

Comparison with other NoSQL cloud databases 

MongoDB Atlas offers many features that make it attractive as a cloud database in web and mobile environments. In practice, however, the question arises whether Atlas is actually a good choice or whether other NoSQL services are better suited depending on the requirements. The following section compares MongoDB Atlas with common alternatives and classifies their respective strengths and weaknesses. 

MongoDB Atlas vs Google Cloud Firestore

Firestore is especially widespread in mobile and frontend focused environments. The comparison is obvious, since both databases are document oriented, schema free, and are often used for similar use cases.

Firestore allows a very fast start and scales automatically, but it tightly binds applications to the Firebase ecosystem. Data access, authentication, and security rules are closely interconnected and rely on proprietary APIs. This results in a relatively high vendor lock in, since switching the database later usually requires significant changes to architecture and code.

In addition, Firestore mainly supports simple, clearly defined queries. Which data can be queried and in what form must be defined early on. MongoDB Atlas offers more flexibility here, as more complex queries and aggregations can be implemented on the server side.

MongoDB Atlas vs Couchbase Capella

Couchbase Capella is also a document oriented NoSQL database that is often mentioned in web and mobile contexts. It is likewise flexible in its document structure and suitable for scalable applications.

Couchbase places a stronger focus on performance and combines document and key value access patterns. Capella also offers features for mobile first scenarios, such as offline synchronization. MongoDB Atlas, on the other hand, is more broadly applicable as a general purpose backend database and provides more flexible query and aggregation capabilities.

MongoDB Atlas vs Azure Cosmos DB (MongoDB API)

Azure Cosmos DB is a globally distributed NoSQL database service from Microsoft. Cosmos DB offers a MongoDB compatible API and therefore covers similar use cases, especially within the Azure ecosystem.

Cosmos DB provides automatic scaling and global replication, but relies on its own implementation of the MongoDB API. As a result, not all MongoDB features are fully available or behave in exactly the same way. MongoDB Atlas uses the original MongoDB engine and offers consistent feature support across versions.

Cosmos DB is strongly tied to the Azure ecosystem, which results in higher vendor lock in. MongoDB Atlas is more flexible with regard to infrastructure and provider changes due to its multi cloud support and self hosting options.

Use cases: when MongoDB Atlas is suitable and when it is not 

Suitable use cases

MongoDB Atlas is particularly well suited for web and mobile applications with dynamic or frequently changing data models. Typical examples include content platforms, social applications, software as a service products, or API centered backends.

It is also suitable for applications with a growing number of users, since scaling and operations are largely automated. Teams benefit from having to deal little or not at all with infrastructure, backups, or updates.

Atlas is also a good choice when complex document structures, aggregations, or flexible queries are required, and when multi regional cloud operation is needed at the same time.

Less suitable use cases

For applications with extremely high latency requirements but simple access patterns, specialized databases may be a better fit.

In scenarios where full control over the infrastructure is required or cloud dependencies are to be avoided, a self hosted database stack may be more appropriate.

Conclusion 

MongoDB Atlas is a powerful and practical cloud database service for modern web and mobile applications. Its strengths lie in schema flexibility, easy scalability, and low operational overhead.

For many typical use cases in web and app development, Atlas offers a balanced combination of flexibility and operational reliability. At the same time, it is important to analyze the specific workload and consider alternative databases when specialized requirements exist.

Sources

1. https://www.ibm.com/topics/database-as-a-service
2. https://www.ibm.com/think/topics/nosql-databases
3. https://www.mongodb.com/docs/atlas/
4. https://medium.com/%40bdhanushka65/what-you-need-to-know-about-mongodb-atlas-b4743727e7f1
5. https://www.mongodb.com/cloud/atlas/multi-cloud
6. https://www.mongodb.com/docs/atlas/global-clusters/
7. https://www.mongodb.com/docs/manual/core/databases-and-collections/
8. https://www.mongodb.com/docs/manual/sharding/
9. https://www.mongodb.com/docs/manual/core/transactions/
10. https://bsonspec.org/
11. https://www.mongodb.com/docs/atlas/monitoring/
12. https://www.mongodb.com/docs/atlas/backup/
13. https://www.mongodb.com/docs/atlas/atlas-search/
14. https://cloud.google.com/firestore/docs/overview
15. https://docs.couchbase.com/cloud/
16. https://risingwave.com/blog/mongodb-vs-firebase-firestore-vs-cosmos-db/?utm_source=chatgpt.com
17. https://www.ionos.at/digitalguide/server/knowhow/couchbase-alternative/?utm_source=chatgpt.com
18. https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/introduction

Image Sources

https://www.mongodb.com/de-de/products/platform

The post MongoDB Atlas an Overview appeared first on Mobile USTP MKL.

Abstract

This paper examines the use of edge computing to enhance modern web applications that require low latency and high interactivity. Traditional cloud architectures struggle with increasing traffic and long network distances, which can lead to congestion and reduce the quality of the user experience. Content Delivery Networks (CDNs) were an early step towards decentralisation because they cache content on servers closer to users, thereby shortening round-trip times. Edge computing builds on this concept by not only moving data, but also parts of the application logic, to nearby edge servers. This paper explains how serverless edge platforms execute eventdriven functions at the network edge to enable faster, more dynamic page rendering and reduce latency, bandwidth requirements and energy usage on mobile devices. It also identifies open challenges for edge-based web applications, including limited resources on edge nodes, managing distributed application state and ensuring security and reliability across diverse infrastructures

1 Introduction

Edge computing has become a key technology for handling growing demands in low-latency data processing and real-time responsiveness. Unlike centralized cloud models, edge computing brings data processing and computation closer to end devices. This is particularly important for applications in the Internet of Things (IoT) and web environments, where responsiveness and localized control are essential. (Gupta et al., 2025, p. 94) (Batool and Kanwal, 2025, p. 1) In theory, the fastest way is always to skip the data transportation over the internet and compute tasks directly on the device (Varghese et al., 2016, p. 21). However, for smaller devices like phones or Internet-of-Things devices the computational power may be too small and has to be sourced out to servers. But real-time applications may have preferred response times under 100 ms, where classic cloud infrastructure cannot provide responses fast enough. (Varghese et al., 2016, p. 21) Web applications benefit from edge computing by reducing access time to distant cloud servers. Placing computing tasks at the network edge enables faster content delivery, dynamic page rendering and low-latency interactions. These benefits are crucial for modern, interactive web services. (Varghese et al., 2016, p. 21) Bringing some of the computation physically closer to the user is part of a greater concept called the Content Delivery Network (CDN). It not only focuses on edge computing but has evolved over time into using AI techniques to predict traffic and optimize routes, 5G technologies and also serverless architectures. (Tyagi, 2025, p. 402) This paper provides a state-of-the-art overview of edge computing for web applications, focusing on latency, CDN evolution and serverless edge platforms.

2 Background: Web applications and Latency

Today, Web-based Information Systems (WBIS) play a crucial role in many sectors such as healthcare, smart cities and industrial automation. However, traditional centralized cloud computing often struggles to meet the high performance requirements of these modern applications. The main problems are bandwidth limitations and long physical distance between a device and the cloud servers. To solve this, data processing must move closer to the source to improve responsiveness and efficiency. (Fazil et al., 2025, p. 1)

2.1 The Necessity of Low Latency

Using a centralized cloud introduces unavoidable delays because data has to travel a long distance. This is a major issue because mobile data traffic is exploding, with things like video streaming accounting for a huge portion of network load (Zhao et al., 2021, p. 1). Sending all this heavy traffic to central clouds causes congestion and wastes bandwidth (Varghese et al., 2016, p. 21). Furthermore, mobile devices often suffer from limited battery life. By processing tasks at the network edge instead of sending them deep into the cloud, we can not only reduce response time but also increase battery life (Javed et al., 2021, p. 16) (Zhao et al., 2021, p. 10). Ultimately, high latency hurts the Quality of Experience (QoE), which is often more important to users than simple technical metrics (Zhao et al., 2021, p. 2).

2.2 Real-Time Interaction and Dynamic Content

The architecture of web applications has evolved significantly. Historically, websites relied on Server-Side-Rendering (SSR), where the server builds the complete page for every request (Vepsäläinen et al., 2023, p. 2). Later, developers shifted towards Client-SideRendering (CSR) and Single Page Applications (SPAs) to create more interactive experiences that feel like desktop applications without reloading the whole page (Vepsäläinen et al., 2023, p. 2). However, mobile devices often have limited computing power and may not handle some complex tasks on their own (Varghese et al., 2016, p. 21). Offloading these tasks to a distant cloud is often too slow. Edge computing helps by allowing dynamic content generation at the network edge, supporting new hybrid techniques like Incremental Static Regeneration (ISR) or the “Islands Architecture”, which allow dynamic content to be loaded efficiently without rebuilding the whole site (Vepsäläinen et al., 2023, p. 3).

2.3 Latency Thresholds and Requirements

Real-time applications have strict limits on response times. Research shows that interactive applications, such as visual guiding systems, work best with a response time between 25ms and 50ms (Varghese et al., 2016, p. 20-21). Traditional cloud infrastructures are often too slow, with round-trip times reaching around 175ms (e.g. between Canberra and Berkeley) (Varghese et al., 2016, p. 21). In industrial or medical scenarios, such delays can cause fatal errors (Zhao et al., 2021, p. 2). To consistently achieve response times fast enough, computing tasks could be moved from the centralized cloud to edge nodes (Cao et al., 2020, p. 85716).

3 Content Delivery Network as a Precursor

Before understanding edge computing, the greater concept to grasp is the Content Delivery Network (CDN) and the necessity to provide content more efficiently (Vepsäläinen et al., 2023, p. 1,4). CDNs represent a significant technological precursor in this evolution, establishing the fundamental concept of decentralizing data to reduce latency and increase reliability (Vepsäläinen et al., 2023, p. 1,3-4).

3.1 Basic Idea and Historical Context

For a long time, websites were hosted on a central web server that served static content (Vepsäläinen et al., 2023, p. 1). In the early 1990s, when the internet and websites were an emerging technology, bandwidth-intensive content such as images and web pages were causing bandwidth congestion and brought up the use of basic web caching (Zhao et al., 2021, p. 4). With the explosion of multimedia traffic in the 21st century, especially videos, centralized server architectures became insufficient due to high latency when transmitting data over long geographical distances (Zhao et al., 2021, p. 4) (Gupta, 2024, p. 2). The fundamental concept of a Content Delivery Network is to lower the physical distance by distributing content across a global network of servers located closer to the end user (Siidorow, 2024, p. 9-10). Instead of routing every request to a central origin server, CDNs deliver static assets, such as HTML documents or media files, from multiple geographically distributed points (Siidorow, 2024, p. 9-10). This architecture significantly reduces the RoundTrip Time (RTT) and reduces the load on the central servers as well as other parts of the network’s infrastructure by minimizing redundant data transmission (Gupta, 2024, p. 2) (Siidorow, 2024, p. 9-10).

3.2 Cache Hierarchies and Infrastructure

The architecture of a CDN is based on the strategic deployment of surrogate servers, or edge nodes at the network’s border (Vepsäläinen et al., 2023, p. 3-4) (Varghese et al., 2016, p. 20-21). These nodes function as proxy caches that replicate and store copies of popular content to maximize availability and access speed and minimize requests to far away central servers (Gupta, 2024, p. 5). The distributed infrastructure represents a distinct shift from the traditional cloud computing model. While cloud computing relies on centralized data centers to gather resources and perform long-term, heavy data analysis, this centralization often introduces latency due to the physical distance to the data source. (Dong et al., 2020, p. 314, 316) (Cao et al., 2020, p. 85715) In contrast, the edge layer decentralizes operations by acting as an executor for real-time, small-scale data processing, while the cloud remains the global coordinator for tasks where high speeds are not a requirement (Dong et al., 2020, p. 318) (Cao et al., 2020, p. 85716). Therefore, edge computing and CDNs do not replace the cloud but supplement it and work together to form a “Cloud-Edge”, where depending on latency and processing power requirements the tasks are either handled locally or forwarded to the central cloud (Dong et al., 2020, p. 315-316) (Fazil et al., 2025, p. 5) (Cao et al., 2020, p. 85717). To manage the limited storage at these edge nodes efficiently, CDNs use sophisticated caching concepts like “Least recently used” (LRU), “Least frequently used” (LFU) and “First in first out” (FIFO) (Zhao et al., 2021, p. 12). In mobile network environments, these caching strategies can extend to caching directly at base stations to further reduce backhaul traffic and response time to improve the user’s Quality of Experience (Zhao et al., 2021, p. 5,9).

3.3 Typical Request Flow

The typical flow of a request in an architecture that uses Content Delivery Networks differs significantly from the traditional communication between client and server. In a typical mobile edge caching model, content requests coming in from the user are first received by edge nodes located in the physically close environment of the user, rather than traveling directly to a far away central data center (Zhao et al., 2021, p. 8-9). To manage this traffic efficiently, CDNs use global load balancing mechanisms that assign each request to the closest available cache server (Dong et al., 2020, p. 318). In this process, the Domain Name System (DNS) redirects the request toward the nearest and most responsive cache node, based on the user’s current network location (Zhao et al., 2021, p. 9). A typical request flow could look like this:

• Routing and Identification:
  When a user requests content, the network identifies the optimal edge node for this request. This selection is handled by load-balancing algorithms that assign the request to the geographically nearest edge nodes (Zhao et al., 2021, p. 9) (Dong et al., 2020, p. 318)
• Content Exploration and Cache Lookup:
  The edge node checks its local storage for the requested asset. If the content is not immediately available on the specific node, the system must search the network to determine the best way to retrieve it at the lowest cost. This is defined as the “content query problem” and may involve forwarding queries to neighboring user equipment or base stations before traveling the whole distance to the central network. (Zhao et al., 2021, p. 10-11)
• Retrieval and Delivery:
  • Cache Hit: If the file is available, it is delivered immediately to the user.
  • Cache Miss: If the content is not available on the node, it is retrieved from higher-level servers, or in the worst case, from the central cloud. The file is then stored locally using replacement policies such as Least Recently Used (LRU) to manage limited storage, and finally served to the user. (Zhao et al., 2021, p. 10-12)
  
  This mechanism not only minimizes latency but also significantly reduces the load on backhaul links by minimizing redundant data traffic to the core network. (Cao et al., 2020, p. 85720)

3.4 Advanced CDN Architectures

As the demand for real-time interactivity and dynamic content grows, the traditional model of simple caching servers has proven to be insufficient in some cases. CDN infrastructures have evolved into complex architectures that build the base for smart edge computing. This is shown by emerging strategies like Distributed, Hybrid and Multi-CDN which are designed to enhance scalability, reliability and performance under varying network conditions.

• Distributed Architectures:
  In modern CDNs, the goal is a highly distributed architecture where numerous edge servers are deployed across multiple Points of Presence (PoPs). This approach focuses on minimizing the physical path between the user and the content and significantly reducing latency and ensuring that high traffic volumes are handled locally rather than overwhelming central data centers. (Tyagi, 2025, 406-407,414)
• Hybrid Architectures:
  Hybrid architectures combine traditional on-premise edge servers with cloud-based CDN services. This approach helps organizations adjust their resources based on real-time demand. During peak traffic, additional workloads can be offloaded to the cloud, while normal operations continue on local infrastructure. This idea is based on the Cloud-Edge where both edge nodes and cloud systems work together. (Tyagi, 2025, 406-407)
• Retrieval and Delivery:
  To ensure high availability and reduce the risk of vendor-specific outages, big enterprises increasingly use Multi-CDN strategies. In this model, the traffic is distributed across CDN services from multiple vendors based on real-time performance metrics, geographical location and cost. If a certain CDN encounters problems like congestion or latency in particular regions or globally, an AIdriven traffic management system can automatically reroute the users to better-performing providers. This hopes to ensure that big platforms like Amazon or Netflix won’t encounter big outages and interrupted service. (Tyagi, 2025, 406-407,414)

These advanced architectures show the significance of transitioning from CDNs as passive content repositories to active intelligent delivery platforms.

4 Edge Computing for Web Applications

While Content Delivery Networks have successfully decentralized the storage of static assets, the modern web requires the decentralization of application logic. Edge computing addresses this by shifting computational tasks from centralized cloud data centers to the edge of the network, closer to the end-user.

4.1 Definition and Operational Principle

Edge computing is defined as a distributed computing structure that brings computation and data storage closer to the location where it is needed, and therefore improves response times and saves bandwidth (Fazil et al., 2025, p. 1). Contrary to traditional cloud computing, where data is transmitted to distant data centers for processing, edge computing uses resources at the edge of the network, e.g. base stations, routers or micro data centers to execute application logic (Cao et al., 2020, p. 85715) (Varghese et al., 2016, p. 20). In the specific context of web applications, it is often defined as Serverless Edge Computing. Here, developers deploy event-driven functions (Function-as-a-Service or FaaS) that run on edge nodes (Batool and Kanwal, 2025, p. 1). Platforms like AWS Lambda@Edge or Cloudflare Workers enable the execution of these functions in response to events (e.g. HTTPS requests) directly at edge nodes (Javed et al., 2021, p. 7-8) (Siidorow, 2024, p. 16,19-20). The serverless model on the edge is especially helpful for web applications, because it reduces the need for always-on servers, instead starting up containers only when requests occur, which optimizes resource usage and costs (Javed et al., 2021, p. 2)

4.2 Key Benefits: Latency, Bandwidth and Real-Time Processing

As already stated, the primary advantage of using edge computing in web development is the necessity to overcome the physical limitations of centralized cloud architecture.

• Latency Reduction:
  By processing requests at the edge, the round-trip time (RTT) to the origin server is significantly reduced (Fazil et al., 2025, p. 1) (Varghese et al., 2016, p. 21). Research shows that in real-time applications such as gaming or augmented reality using a distant cloud poses serious latency problems due to geographical location (Varghese et al., 2016, p. 21).
• Bandwidth Efficiency:
  Edge computing takes a lot of load off the central server infrastructure by processing data locally. Instead of transmitting lots of raw data to the cloud, edge nodes can filter, aggregate, or compress data and forward only relevant data to the central infrastructure (Varghese et al., 2016, p. 21). This is especially critical for bandwidthheavy content like video streaming or Augmented and Virtual Reality applications where a lot of congestion can be prevented by processing on the edge of the network (Gupta, 2024, p. 3).
• Real-Time Capabilities:
  Because edge computing is close to the data source, it can process information with much lower delay. This reduced transmission time enables realtime responses for the user and supports fast, context-aware decisions in web applications. (Fazil et al., 2025, p. 1-2)

4.3 Beyond the CDN: From Caching to Computing

Traditionally, Content Delivery Networks focused on caching static assets to reduce latency and origin server load (Vepsäläinen et al., 2023, p. 1) (Tyagi, 2025, p. 401-402). Edge computing evolves this model by transforming edge nodes from passive caches into active execution environments used to process dynamic content (Vepsäläinen et al., 2023, p. 4) (Tyagi, 2025, p. 411). This shift enables programmable capabilities where data analysis, security filtering and content generation happen at the edge of the network (Tyagi, 2025, p. 411) (Cao et al., 2020, p. 85715). Therefore, web applications can implement dynamic rendering strategies like server-side rendering (SSR) or incremental static generation (ISR), directly at the edge to optimize the Quality of Experience (QoE) for the end-user (Vepsäläinen et al., 2023, p. 1,3,5).

4.4 Edge Functions and Runtimes

Edge logic is primarily implemented via Serverless Edge Computing or Function-as-a-Service (FaaS), which allows developers to deploy stateless functions without infrastructure management (Batool and Kanwal, 2025, p. 1-2). The runtimes used generally fall into two categories:

• MicroVM-based:
  Architectures like AWS Lambda@Edge utilize lightweight virtualization (e.g. Firecracker) to provide isolation and broad language support, though they can struggle with “cold start” latencies when initialized (Siidorow, 2024, p. 16-17).
• Isolate-based:
  Platforms like Cloudflare Workers or Deno Deploy use V8 isolates to run multiple functions within a single process. In this approach “cold starts” are eliminated and it reduces memory usage, but it is typically restricted to JavaScript and WebAssembly environments (Siidorow, 2024, p. 22-23,27-28)

These runtimes enable developers to execute custom code directly at the network periphery, allowing them to shape client requests and server responses, providing faster response times and new possibilities (Vepsäläinen et al., 2023, p. 1).

1. Dynamic Request Manipulation:
   Functions can dynamically assemble web pages or tailor content in real-time based on the user’s location or device type, rather than serving generic static resources (Gupta, 2024, p. 8).
2. Media Optimization:
   Edge functions can perform on-thefly transformations of media assets, such as resizing, cropping or formatting images and videos to match the capabilities of the requesting device (Gupta, 2024, p. 8).
3. Security and Access Control:
   Complex access control logic can be implemented directly at the edge to allow the system to validate requests without long round trips to the origin server (Gupta, 2024, p. 8).
4. Real-Time AI Inference:
   Edge nodes are capable of running lightweight AI models to perform tasks such as realtime content analysis, automated content moderation, or media analytics closer to the end-user. (Gupta, 2024, p. 5)

4.5 Challenges and Limitations

Deploying web applications at the edge of the network can introduce challenges compared to using a centralized cloud.

1. Resource Constraints:
   Edge nodes often possess limited computational power and memory compared to cloud data centers. Therefore, highly efficient algorithms and effective resource scheduling are needed (Batool and Kanwal, 2025, p. 14).
2. State Management:
   Connecting to centralized databases from the edge can reintroduce latency due to the round-trip time required for queries. While data replication to the edge may be a solution, it introduces risks regarding data consistency and “replication lag”, making it difficult to maintain a synchronized state across all nodes for real-time applications. (Siidorow, 2024, p. 29)
3. Security:
   Since Edge Functions are usually limited to a small scope and need fewer privileges, they often have a significantly reduced attack surface compared to full applications in containerized or virtual environments (Siidorow, 2024, p. 28)
4. Cold Starts:
   Cold starts may occur when a certain edge function is not used for a longer time. Depending on the runtime, cold starts can present a significant problem by causing delays during complex workloads such as AI functions, which negate the latency benefit of edge functions if they take longer than the original round trip time to the data center (Siidorow, 2024, p. 27)

5 Conclusion

This work demonstrates how edge computing builds upon the concepts of traditional content delivery networks (CDNs) to overcome the latency and bandwidth limitations of centralized cloud architectures. Modern web-based systems depend on real-time interaction, rich media, and personalization. In such scenarios, long network paths to distant data centers can quickly slow down applications. CDNs reduce this issue by caching static content at the edge; meanwhile, edge computing builds on this model by running parts of the application logic on servers close to the user. For web applications, this shift enables faster handling of requests, more responsive dynamic content and an improved quality of experience, particularly on mobile devices or in scenarios that require a lot of bandwidth. However, serverless edge platforms also introduce new challenges. Edge nodes have limited computing and memory resources, and coordinating distributed state is more challenging. Cold starts and heterogeneous runtimes can further reduce performance if not managed effectively. Overall, current research indicates that the cloud and the edge should be used together. Content Delivery Networks (CDNs) and serverless edge platforms handle latency-sensitive tasks near the user, while centralized cloud systems remain important for computationintensive workloads and long-term data storage. In the future, CDN and edge strategies will become increasingly prominent, as realtime services, IoT deployments, and rich media applications continue to grow and push performance requirements beyond what centralized cloud architectures can reliably provide.

Acknowledgments

Parts of the wording of this manuscript were supported by generative AI tools for language editing. All scientific content, structure
and conclusions were created and verified by the author.

References

1. Iqra Batool and Sania Kanwal. 2025. Serverless Edge Computing: A Taxonomy, Systematic Literature Review, Current Trends and Research Challenges.
   arXiv:2502.15775 [cs.NI] https://arxiv.org/abs/2502.15775
2. Keyan Cao, Yefan Liu, Gongjie Meng, and Qimeng Sun. 2020. An Overview on Edge
   Computing Research. IEEE Access 8 (2020), 85714–85728. doi:10.1109/ACCESS.2020.
   2991734
3. Yunqi Dong, Jiujun Bai, and Xuebo Chen. 2020. A Review of Edge Computing Nodes Based on the Internet of Things. In Proceedings of the 5th International Conference on Internet of Things, Big Data and Security (IoTBDS). 313–320.
   doi:10.5220/0009407003130320
4. A. W. Fazil, A. Ghairat, and A. J. Kohistani. 2025. Advancing Web-Based Information
   Systems Performance via Edge Computing: A Comprehensive Systematic Review.
   GAME 2, 4 (2025), 1–20. doi:10.29103/game.v2i4.24189
5. Ragini Gupta, Claudiu Danilov, Josh Eckhardt, Keyshla Bernard, and Klara Nahrstedt.
   2025. Characterizing Container Performance in Edge Computing. In Proceedings of
   the ACM SIGCOMM 2025 Posters and Demos (Coimbra, Portugal) (ACM SIGCOMM
   Posters and Demos ’25). Association for Computing Machinery, New York, NY, USA,
   94–96. doi:10.1145/3744969.3748438
6. Sachin Gupta. 2024. Enhancing Content Delivery with Edge Computing in Media and
   Entertainment. Zenodo. doi:10.5281/zenodo.13933556
7. Hamza Javed, Adel N. Toosi, and Mohammad S. Aslanpour. 2021. Serverless Platforms
   on the Edge: A Performance Analysis. arXiv:2111.06563 [cs.DC] https://arxiv.org/
   abs/2111.06563
8. Mikael Siidorow. 2024. Survey of Serverless Edge Computing for Web Applications.
   doi:10.13140/RG.2.2.13600.39680
9. Anuj Tyagi. 2025. Optimizing digital experiences with content delivery networks:
   Architectures, performance strategies, and future trends. World Journal of Advanced
   Research and Reviews 7, 2 (01 2025), 401–417. doi:10.30574/wjarr.2020.7.2.0230
10. Blesson Varghese, Nan Wang, Sakil Barbhuiya, Peter Kilpatrick, and Dimitrios
    Nikolopoulos. 2016. Challenges and Opportunities in Edge Computing. In
    2016 IEEE International Conference on Smart Cloud (SmartCloud). IEEE, 20–26.
    doi:10.1109/SmartCloud.2016.18
11. Juho Vepsäläinen, Arto Hellas, and Petri Vuorimaa. 2023. Implications of Edge Computing for Static Site Generation. arXiv:2309.05669 [cs.HC] https://arxiv.org/abs/
    2309.05669
12. Yuhan Zhao, Wei Zhang, Longquan Zhou, and Wenpeng Cao. 2021. A Survey on
    Caching in Mobile Edge Computing. Wireless Communications and Mobile Computing 2021 (2021), 1–21. doi:10.1155/2021/5565648

The post SOTA | Edge Computing for Web Applications appeared first on Mobile USTP MKL.

My idea was to create a virtual museum that can be accessed via QR codes printed on ads displayed directly in the stations. This way, people can learn about the station’s history while waiting for the train, riding it, or exploring the station. The aim is to make the project appealing not only to tourists but also to locals.

For my poster and prototype, I chose Karlsplatz Station as an example because it has a fascinating history and is notoriously difficult to navigate due to its many levels and countless exits.

The slogan on the poster plays with the phrase “finding out”, which not only refers to literally finding a way out of the complex passages and levels of Karlsplatz, but also to discovering the station’s history. The language is English because many tourists pass through Karlsplatz every day. When the campaign is implemented for other stations, such as Seestadt, which is mainly used by locals, a German version of the poster would make more sense. This particular poster could be displayed not only on the platforms but also near the exits, as the advertisement directly references that scenario.

After scanning the QR code, the content page for Karlsplatz opens. It contains four paragraphs focusing on the history, construction, and current role of Karlsplatz, supported by relevant images. There is also an option to listen to the content, the audio version should not exceed five minutes to keep the information concise and engaging. The language can be changed as well.

If you’re interested in the history of other stations, you can visit the station overview and search for them. There is also a map where you can check out your surroundings and nearby stations. In the “More” section, there could be items such as the imprint, data policies, contact information, or links to other services and apps provided by the City of Vienna.

This Project is just a concept and not affiliated with Wiener Linien in any way. It is a purely academic student project, created for educational purposes only. No financial support, sponsorship, or compensation has been received from Wiener Linien or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

Sources:

• Person auf dem Poster: Foto von Nathan Dumlao auf Unsplash
• Karlsplatzbild: Foto von Shery Arturova auf Unsplash
• Karte von https://www.openstreetmap.org/#map=15/48.18031/16.36414
• Baustelle Karlsplatz Bild: https://newsv2.orf.at/stories/2424487/2425558/
• United kingdom icons created by Freepik – Flaticon: https://www.flaticon.com/free-icons/united-kingdom

The post Print2Mobile | TrackBack Vienna – Get to know Viennas Subway System (Print2Mobile Project) appeared first on Mobile USTP MKL.