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

Other Projects

Swiva is a mobile app for saving ideas, places, recipes and activities from TikTok, Instagram, Maps and the web, and actually turning them into plans.

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

Working in event management and also as staff during some of Austria’s biggest festivals, you start noticing some problems when it comes to registration of your clients: The company I currently work with (Adrenalin Company) specialises in the renting and operation high-thrill event tools that have certain risks associated to them in the event of misuse. Therefore, participants are required to sign so called liability exclusion disclaimers before attending.

The problem

Solution

Clients can read the liability exclusion disclaimer and sign it easily using their smartphone. Not only does this reduce the need for printed forms, but it also allows all participants to sign simultaneously, reducing overall wait time. After filling out and submitting the form, the participants are given a personalised QR-code that contains all the relevant information for us organisers.

Future

In future versions of this tool, the website would display the information in the system-used language, making it more accessible. The submitted information would be stored securely on a dedicated server for the legally required duration. On the other hand, there is a need to develop a specialised QR-code scanner application, that can read the participants codes and cross check them with the database in order to check their validity.

All in all, a user would first scan the QR-code on the poster and read, sign and submit the disclaimer. Then they would go to the event booth, where a staff member would scan each participant’s personalised code to verify its validity before they can enjoy the attraction.

Disclaimer: This project is not associated with BAGJUMP in any way. It is a purely academic student project, created for educational purposes only.

Link to the website: https://karavam.github.io/QR-Code-Website/

The post Print2Mobile Event registration tool 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

Other Projects

Swiva is a mobile app for saving ideas, places, recipes and activities from TikTok, Instagram, Maps and the web, and actually turning them into plans.

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

We’ve all been there, standing in front of the fridge or in the supermarket aisle not knowing what to cook. Meanwhile, tons of perfectly good food end up in the trash every day.

Dishcovery not only inspires creativity in the kitchen — it makes sustainability simple, digital, and rewarding.

This project is not affiliated with BILLA or the REWE Group 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 BILLA or any other company. Any use of names or logos is solely for demonstration purposes within the prototype.

iPhone design by Luis Orea
Icons designed by Kryston Schwarze https://coolicons.cool/
Illustrations/Icons designed by Freepick www.freepik.com

Other Projects

Swiva is a mobile app for saving ideas, places, recipes and activities from TikTok, Instagram, Maps and the web, and actually turning them into plans.

The post Print2Mobile | Dishcovery appeared first on Mobile USTP MKL.

Nativescript – eine kurze Vorstellung

Mit NativeScript, das 2015 auf den Markt kam, wurde ein Framework präsentiert, das plattformübergreifende mobile Apps ermöglicht und zugleich direkten Zugriff auf die nativen Funktionen von Android und iOS bietet. Seit dessen Einführung wird es kontinuierlich weiterentwickelt und hat sich zu einer stabilen Lösung für die App-Entwicklung etabliert. NativeScript erlaubt es, Apps mit bekannten Web-Technologien wie JavaScript, TypeScript, Angular oder Vue.js zu erstellen, wodurch der Einstieg für Web-Entwickler besonders einfach ist. Gleichzeitig werden die UI-Komponenten direkt nativ gerendert, was eine nahezu maximale Leistung gewährleistet. Ein Großteil des Codes kann zwischen Android und iOS weiterverwendet werden, wodurch Entwicklungszeit und -kosten reduziert werden. Damit kombiniert NativeScript die Vorteile plattformübergreifender Entwicklung mit direktem API-Zugriff und nativer Performance.

Mit diesem Wissen im Gepäck gelang es mir meine Erstentwicklung als reine WebApp in Angular ohne grundlegenden Neuanfang im nativen Bereich durchführen. Das hat mir die Möglichkeit eröffnet viele Teile der ursprünglichen Angular-Programmierung in eine App zu übertragen, auch wenn dies mit einer gewissen Komplexität einherging.

Von einer Web-App zu einer nativen App

Der Wechsel von der ursprünglichen Angular Web-App zu einer nativen App mit NativeScript stellte einen entscheidenden Entwicklungsschritt dar. Während die erste Version ausschließlich im Browser funktionierte und auf klassische Web-Komponenten ausgelegt war, verlagerte sich der Fokus nun auf die mobile Nutzung, native Performance und eine tiefere Integration in die jeweilige Plattform. Diese Veränderung erforderte nicht nur technisches Know-how, sondern auch ein grundlegendes Umdenken im App-Design. Die Benutzeroberfläche musste für mobile Endgeräte neu konzipiert werden, denn alleine responsive Layouts reichten nicht mehr aus. Stattdessen waren eine intuitive Navigation, Gestensteuerung und schnelle Ladezeiten gefragt. Technisch konnten viele Angular-Module und Services zwar grundsätzlich übernommen werden, jedoch waren umfangreiche Anpassungen notwendig, insbesondere beim Routing, der Datenbindung und dem Zugriff auf systemnahe Funktionen wie dem Dateispeicher.

Optimierter Suchalgorithmus

Der ursprüngliche Suchalgorithmus stellte einen klaren Engpass dar, da jede Filteranfrage direkt an die externe API gesendet wurde. Das führte zu langen Ladezeiten und unnötiger Netzwerklast.

Mit dem neuen, optimierten Ansatz werden die Rezeptdaten nun beim Start der Anwendung automatisch aus der API geladen und in die lokale Datenbank geschrieben. Die Suche erfolgt anschließend vollständig serverseitig über diese Datenbank, wodurch Abfragen deutlich schneller und stabiler laufen. Gleichzeitig bleibt die Filterlogik flexibel: Nutzer:innen können nach Kategorie, Alkoholgehalt und Zutaten suchen, ohne dass alle Kriterien zwingend gesetzt sein müssen.

Die “Signature”-Drinks

Dieses neue Feature bietet dem/der User:in die Möglichkeit, sich seinen/ihren Drink (Cocktail) selbst nach eigenen Wünschen zusammenzustellen. Diese Drinks in Form von Rezepten werden entsprechend gekennzeichnet und sind mit dem/der Ersteller:in verknüpft. Die Datenspeicherung erfolgt in der selben Tabelle, wo die Drink Rezepte der API abgespeichert sind. Nach dem Anlegen eines “Signature”-Drinks stehen dem/der Ersteller:in die Möglichkeit zur Verfügung den Drink . Hier ein Blick in die App (Bild folgt):

Weitere Features/Verbesserungen

Redesign

Mit dem Wechsel von einer WebApp auf eine native Mobile-App wurde das bestehende Design nicht vollständig neu entwickelt, sondern gezielt modernisiert und an mobile Nutzungsszenarien angepasst. Der Fokus lag dabei auf einer klareren visuellen Struktur, einer verbesserten Bedienbarkeit sowie einem konsistenten Erscheinungsbild über alle Ansichten hinweg.

Ein wesentlicher Schritt war die Umstellung des UI-Designs auf das Utility-First-Framework Tailwind CSS, das eine deutlich effizientere Gestaltung und höhere Flexibilität bei der Komponentenentwicklung ermöglicht. Dadurch konnten wiederkehrende Layouts vereinheitlicht, Abstände und Typografie präzise gesteuert und das gesamte Erscheinungsbild minimalistischer und moderner gestaltet werden.

Zutaten Suchfunktion

Bisher musst man sich durch eine lange Liste von Zutaten “quälen” – mit einem neuen Suchfeld bei den Zutaten wurde dies nun deutlich vereinfacht.

Herausforderungen im Entwicklungsprozess

Anbei zwei wesentliche Herausforderungen, die sich während der Entwicklungsarbeit zunehmend herauskristallisiert haben:

Die mobile Umsetzung von MixMatch mit NativeScript und Angular brachte einige technische und strukturelle Herausforderungen mit sich. Der Umstieg von der bisherigen Angular-Webumgebung auf NativeScript erforderte eine Einarbeitung in neue Syntaxkonzepte und native UI-Komponenten. Viele Layouts und Funktionen ließen sich nicht direkt übernehmen, sondern mussten gezielt an mobile Anforderungen angepasst werden. Zudem NativeScript auch noch ein sehr “junges” natives Framework ist und die Dokumentation derzeit noch nicht als allzu ausgereift erscheint.

Gleichzeitig wurde deutlich, dass Teile des bestehenden Codes, insbesondere im Hinblick auf Wartbarkeit und Performance auf mobilen Geräten, zu komplex aufgebaut waren. Um dem entgegenzuwirken, habe ich z. B. Übersetzungen in separate Lokalisations-Files ausgelagert, anstatt sie direkt im Code zu halten. Auch die Datenverarbeitung wurde angepasst: Statt verschachtelter Aufrufe zu der thecocktaildb API erfolgt die Filterung nun über eine lokale Datenbank, nachdem alle Daten der externen API einmalig gespeichert wurden.

Resümee mit Ausblick

Das Projekt stellte in mehrfacher Hinsicht eine wertvolle Lernerfahrung dar – insbesondere durch den mutigen Schritt, mit NativeScript in ein für mich völlig neues Framework einzusteigen. Dieser Ansatz bot die Gelegenheit, die Stärken und Schwächen der Plattform unmittelbar kennenzulernen: Auf der einen Seite die hohe Flexibilität, die tiefe Integration nativer Funktionen und die Möglichkeit, moderne Frontend-Technologien wie Angular und Tailwind zu kombinieren; auf der anderen Seite aber auch die typischen Herausforderungen eines jungen Frameworks – etwa eingeschränkte Dokumentation, komplexe Build-Prozesse und teils unerwartete Kompatibilitätsprobleme.

Gerade dieser direkte Umgang mit den Schattenseiten und positiven Aspekten des Frameworks hat jedoch den größten Lerneffekt gebracht. Es entstand ein tieferes Verständnis für mobile App-Architekturen, die Bedeutung einer sauberen Code-Struktur.

Auch nach Abschluss dieser Entwicklungsphase bleiben einige naheliegende Erweiterungen vorstellbar, die sich mittelfristig umsetzen lassen. Dazu zählt etwa eine Kommentarfunktion, mit der Nutzer:innen direkt Rückmeldung zu einzelnen Drinks geben oder sich austauschen können. Ebenso wäre es denkbar, die „Signature Drinks“ für andere sichtbar zu machen. Mit der individuellen Möglichkeit, eigene Rezepturen anderen Usern/Userinnen sichtbar zu machen, können persönliche Rezeptideen einem weiten Publikum präsentiert werden.
Ergänzend ließe sich eine einfache Einkaufsliste integrieren, in der fehlende Zutaten gesammelt und als Liste exportiert werden könnte. Diese funktionalen Erweiterungen würden, wie üblich, Hand in Hand mit weiterem Bugfixing, Code-Optimierungen und kleineren UI-Verbesserungen erfolgen, um die App sowohl technisch als auch inhaltlich weiter zu stabilisieren, der Benutzerfreundlichkeit hin zu optimieren und auszubauen.

Beitragsbild: dieses wurde mittels Einsatz von KI erzeugt

The post Projekt SS25 | MixMatch (Fortsetzung) appeared first on Mobile USTP MKL.

In diesem Artikel werden fünf gängige Architektur-Muster vorgestellt, die wichtigsten Auswahlkriterien erklärt und eine praktische Check­liste für die Entscheidung geliefert. So entsteht bereits vor dem ersten Commit eine solide Basis für eine reibungslose Entwicklung.

Klassische Schichten-Architektur

Die bekannteste Herangehensweise ist die klassische Schichten-Architektur. Dabei wird eine Anwendung in drei Teile gegliedert:

In der Praxis:

Einsatzszenario:

Die klassische Drei-Schichten-Architektur eignet sich besonders für kleine bis mittelgroße Anwendungen und Solo- oder Kleinteam­projekte, weil sie schnell aufgesetzt ist und eine klare Trennung von UI, Logik und Datenzugriff bietet. Hält sich die Domäne jedoch in Grenzen, lässt sich damit langfristig gut arbeiten. Wachsen jedoch Funktionsumfang, Geschäftsprozesse oder Teamgröße, sollte man rechtzeitig über Modularisierung, DDD oder Microservices nachdenken, um die Wartbarkeit nicht zu gefährden.

Frontend-Pattern: MVC und MVVM

In Frontend-Anwendungen treffen Darstellung, Logik und Nutzereingaben direkt aufeinander – ohne klare Struktur wird der Code schnell unübersichtlich. MVC und MVVM sind zwei bewährte Muster, die helfen, diese Bereiche zu trennen und Benutzeroberflächen wartbarer und übersichtlicher zu gestalten.

Model-View-Controller (MVC):

• Model: Alle Daten und Geschäftslogik.
• View: Das, was man sieht und anklickt.
• Controller: Die Brücke dazwischen – nimmt Eingaben der View entgegen und aktualisiert Model oder View.MVC trennt klar, wer was tut, und macht es leicht, einzelne Teile auszutauschen.

Model-View-ViewModel (MVVM):

• Ähnlich wie MVC, ergänzt aber das ViewModel, das View und Model synchron hält.
• Änderungen am Model „binden“ sich automatisch in die View ein und umgekehrt.MVVM ist besonders beliebt in modernen UI-Frameworks (z. B. SwiftUI, Jetpack Compose), weil es mit Datenbindung und Deklarativität perfekt harmoniert.

Einsatzszenario:

• MVC eignet sich für einfache Web-Apps oder klassische Desktop-Anwendungen.
• MVVM glänzt, wenn Frameworks Datenbindung anbieten und man den UI-Code sauber von Logik fernhalten will.

Monolith vs. Microservices

Wenn die Anwendung wächst, stellt sich die Frage, ob man alle Funktionen in einem großen Block (Monolith) lässt oder in kleine, eigenständige Dienste (Microservices) aufteilt.

Einsatzszenario:

Für kleine Teams und einfache Projekte bleibt der Monolith oft die pragmatischere Wahl. Bei hoher Komplexität, vielen Teams oder strengen Skalierungsanforderungen lohnt sich der Umstieg auf Microservices.

Domain-Driven Design (DDD)

Domain-Driven Design ist ein Ansatz, bei dem der Fokus auf dem fachlichen Kern einer Anwendung liegt, also auf dem, was das System inhaltlich wirklich tut. Statt sich zuerst mit Frameworks oder Datenbanken zu beschäftigen, geht es darum, die Abläufe und Begriffe einer bestimmten Domäne, zum Beispiel im Ressourcenmanagement, in der Buchhaltung oder im E-Commerce genau zu verstehen und diese im Code richtig abzubilden. Um diese Idee in der Praxis umzusetzen, nutzt DDD verschiedene Konzepte, die helfen, komplexe Systeme verständlich zu strukturieren und die Zusammenarbeit zwischen Fachexperten und Entwickelnden zu verbessern. Besonders wichtig sind dabei Ubiquitous Language, Bounded Contexts und der Unterschied zwischen Entities und Value Objects.

Ubiquitous Language bedeutet, dass Entwickelnde und Fachexperten eine gemeinsame Sprache verwenden. Fachbegriffe wie „Buchung“, „Ressource“ oder „Projekt“ tauchen dabei direkt im Code auf, zum Beispiel als Klassen oder Methoden. Das sorgt dafür, dass alle dasselbe Verständnis haben und sich leichter austauschen können.

Bounded Contexts helfen dabei, eine große und komplexe Domäne in klar abgegrenzte Bereiche zu unterteilen. Jeder Bereich hat sein eigenes Modell und eigene Regeln. So bleibt der Code übersichtlich, und Änderungen in einem Teil der Anwendung führen nicht automatisch zu Problemen in einem anderen.

Bei Entities handelt es sich um Objekte mit einer eindeutigen Identität, wie zum Beispiel ein Kunde, der sich im Laufe der Zeit verändern kann. Value Objects dagegen, wie ein Geldbetrag, sind unveränderlich und werden nur durch ihre Werteigenschaften beschrieben.

Einsatzszenario:

Wenn die Domäne komplex ist und viele Experten involviert sind, sorgt DDD dafür, dass alle dasselbe Vokabular nutzen, im Code und in Meetings. Das reduziert Missverständnisse und verbessert die Wartbarkeit.

Event-Driven Architektur & CQRS

Bei modernen Anwendungen, die in Echtzeit reagieren oder viele Prozesse gleichzeitig verarbeiten müssen, stoßen klassische, linear aufgebaute Systeme schnell an ihre Grenzen. Um diesen Anforderungen gerecht zu werden, haben sich neue Architekturansätze wie die Event-Driven Architecture und Command Query Responsibility Segregation etabliert.

Event-Driven Architecture (EDA):

Statt dass Komponenten direkt miteinander kommunizieren, reagieren sie auf Ereignisse, sogenannte Events. Wenn beispielsweise eine Bestellung aufgegeben wird, löst dieses Ereignis weitere Aktionen aus, wie den Versand einer Bestellbestätigung oder das Aktualisieren des Lagerbestands. Das System bleibt dadurch flexibel, entkoppelt und kann leicht erweitert oder skaliert werden.

Command Query Responsibility Segregation (CQRS):

CQRS trennt Lese- und Schreibvorgänge klar voneinander: Commands verändern den Zustand eines Systems (zum Beispiel „Erstelle Rechnung“), während Queries nur Daten abfragen (etwa „Hole Rechnungsübersicht“). Durch diese Trennung lassen sich beide Bereiche gezielt optimieren. In Verbindung mit Event Sourcing, bei dem jede Zustandsänderung als Ereignis gespeichert wird, können Abläufe besser nachvollzogen und Systeme insgesamt stabiler und fehlertoleranter gestaltet werden, besonders bei komplexen oder verteilten Anwendungen.

Einsatzszenario:

IoT-Netzwerke, Echtzeitanalysen, große Webplattformen oder Finanz­transaktionen, bei denen Latenzen niedrig und Nachvollziehbarkeit hoch sein müssen.

Fazit

In meinem Semesterprojekt habe ich eine Webapp nach dem klassischen Drei-Schichten-Prinzip aufgebaut – Benutzeroberfläche, Geschäftslogik und Datenzugriff. Als alleiniger Entwickler konnte ich so in kurzer Zeit neue Features hinzufügen, ohne dass das System unübersichtlich wurde.

In meiner aktuellen Arbeit an einer umfangreichen Ressourcenmanagement-Plattform mit über zehn Entwicklerinnen und Entwicklern reicht dieses einfache Grundgerüst allerdings nicht mehr aus. Deshalb sind wir auf Domain-Driven Design umgestiegen und nutzen im Code jetzt echte Fachbegriffe wie „Ressource“, „Room“ oder „Desk“. Diese Umstellung hat nicht nur die Einarbeitung neuer Teammitglieder erleichtert, sondern auch die Abstimmung mit den Fachabteilungen deutlich beschleunigt.

Im Laufe verschiedener Projekte ist mir immer wieder aufgefallen, wie schnell selbst kleine Änderungen an der Architektur später großen Aufwand nach sich ziehen können. Wer sich bereits zu Beginn Gedanken über mögliche Wachstums- und Team­szenarien macht, schafft eine solide Grundlage für spätere Erweiterungen. Mir wurde dabei deutlich, dass sich ein wenig zusätzliche Planung im Vorfeld vielfach auszahlt, sei es durch eine bewusste Strukturierung in Schichten, eine klare Trennung fachlicher Kontexte oder den Einsatz von Entkopplungs­mechanismen. Dieses Vorgehen sorgt nicht nur für verständlicheren Code, sondern erleichtert auch das Hinzukommen neuer Mit­arbeiterinnen und Mitarbeiter. Letztlich zahlt sich jeder Moment, den man in die Architektur­entscheidung investiert, in Form von Zeitersparnis und weniger technischen Stolpersteinen aus.

Links

• https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures

• https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles

• https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices

• https://martinfowler.com/microservices

The post Blog | Software Architekturen: Überblick und Entscheidungs­hilfe appeared first on Mobile USTP MKL.

In diesem Beitrag möchte ich den Aufbau der Anwendung, die verwendeten Technologien sowie einige Herausforderungen und Learnings während der Umsetzung vorstellen.

Technologie-Stack

Das Club Dashboard wurde als moderne Webanwendung mit Fokus auf Skalierbarkeit, Sicherheit und einfache Erweiterbarkeit entwickelt.
Hier ein Überblick über die zentralen Technologien:

Framework: Next.js (App Router)

Für das Frontend kam Next.js mit dem neuen App Router zum Einsatz. Diese Architektur erlaubt serverseitiges Rendering (SSR), API-Routen und eine saubere Trennung von Client- und Server-Komponenten. Dadurch konnte ich sowohl UI-Logik als auch Backend-Funktionalität innerhalb eines Frameworks umsetzen.

Vorteile:

• Serverseitiges Rendering für bessere Performance und SEO
• Integrierte API-Routen für serverseitige Logik (z. B. Payment Handling)
• Moderne Struktur durch den App Router

Data Layer: Convex

Anstatt einer klassischen REST- oder GraphQL-API habe ich mich für Convex entschieden – eine innovative Backend-as-a-Service-Lösung, die reaktive Datenabfragen, serverseitige Funktionen und Auth-Integration out of the box bietet.

Convex ermöglicht es, Daten- und Serverlogik in TypeScript zu schreiben und nahtlos mit dem Frontend zu verbinden. Dadurch entfällt ein Großteil der sonst notwendigen API- und Datenbankkonfiguration.

Styling & UI: TailwindCSS & shadcn

Für das Styling habe ich auf TailwindCSS gesetzt – ein Utility-First-CSS-Framework, das schnelles Prototyping und einheitliches Design ermöglicht.
Zusätzlich kam shadcn zum Einsatz, eine leichtgewichtige Component Library mit Fokus auf Barrierefreiheit, Dark Mode und Customizability.

Vorteile dieser Kombination:

• Konsistentes UI mit klarer Design-Sprache
• Wiederverwendbare Komponenten
• Effiziente Entwicklung durch Utility-Klassen
• Code Ownership: Components werden einfach ins Projekt kopiert

Authentifizierung: Clerk

Die Authentifizierung wird durch Clerk umgesetzt – denselben Anbieter, den ich bereits im ersten Semesterprojekt genutzt habe. Clerk bietet ein modernes User Management inklusive OAuth-Integration und JWT-Handling, was eine einfache Verbindung mit Convex und Next.js ermöglicht.

Durch Clerk konnte ich schnell eine sichere Login-, Logout- und Session-Logik aufsetzen, ohne selbst komplexe Authentifizierungssysteme implementieren zu müssen.

Payment Provider: Stripe

Ein zentrales Feature dieses Projekts war die Integration von Stripe als Payment Provider. Nutzer:innen können direkt über die Website eine Skiausfahrt buchen und bezahlen.
Dazu wurde das Stripe Checkout-System in die App eingebunden – inklusive Webhook-Handling, um Payment-Status-Änderungen serverseitig zu verarbeiten.

Beispielhafte Flows:

• User wählt eine Ausfahrt aus → Klick auf „Buchen“
• Stripe Checkout öffnet sich → Zahlung erfolgt
• Stripe sendet einen Webhook an das System → Buchung wird bestätigt und gespeichert

Diese End-to-End-Integration war der Kern des Projekts und erforderte ein gutes Zusammenspiel zwischen Frontend, Convex Backend und Stripe Webhooks.

Kommunikation & Webhooks

Ein spannender Teil des Projekts war die Kommunikation zwischen den verschiedenen Systemen.
Sowohl Stripe als auch Clerk arbeiten mit Webhooks, um Echtzeit-Informationen an das System zu senden (z. B. erfolgreiche Zahlungen oder neue Benutzer).
Die Webhooks werden über API-Routen in Next.js empfangen und anschließend in Convex weiterverarbeitet – beispielsweise um Buchungsdaten zu aktualisieren oder Rechnungen zu speichern.

Herausforderungen & Learnings

Während der Entwicklung gab es mehrere interessante Herausforderungen:

• Webhook-Handling: Das Zusammenspiel von Stripe, Clerk und Convex erfordert saubere Trennung von Sicherheits- und Logikschichten. Insbesondere das Validieren von Webhook-Signaturen war anfänglich fehleranfällig.
• Datenmodellierung in Convex: Da Convex ein eigenes Datenmodell nutzt, war es notwendig, sich in dessen Schema-System einzuarbeiten.
• SSR + Client-Komponenten: Der Wechsel zwischen Server- und Client-Komponenten im Next.js App Router war zunächst ungewohnt und erforderte ein gutes Verständnis des Rendering-Modells.

Trotz dieser Hürden war die Entwicklung äußerst lehrreich – vor allem im Hinblick auf Payment-Flows, Security und API-Kommunikation.

Fazit

Das Club Dashboard war ein spannendes Projekt, das mir erstmals die Umsetzung einer vollständigen End-to-End-Integration mit Stripe ermöglicht hat.
Durch den Einsatz moderner Tools wie Next.js, Convex, Clerk und Stripe konnte ich einen funktionalen MVP umsetzen, der reale Buchungsprozesse abbildet.

Besonders interessant war zu sehen, wie gut sich die verschiedenen Services über Webhooks und API-Routen integrieren lassen – und wie wichtig saubere Datenflüsse und Sicherheit in einem Payment-System sind.

Im nächsten Schritt plane ich, das Dashboard um weitere Funktionalitäten zu erweitern, um einem produktionsreifen Produkt näher zu kommen, das sich veröffentlichen und vertreiben lässt.

Screenshots

The post Projekt | Powda Club-Dashboard appeared first on Mobile USTP MKL.