Dart’s viability in full-stack development: a case study

In 2012, Google released the Dart language which, more recently, due to Flutter, has received a boost in popularity and is being often referred to as a full-stack language / ecosystem suitable for developing front-end and back-end solutions. However, aside from Flutter for mobile, Dart usage is stil...

Full description

Bibliographic Details
Main Author: Aguiar, Sérgio Gabriel Pacheco de (author)
Format: masterThesis
Language:eng
Published: 2022
Subjects:
Online Access:http://hdl.handle.net/10773/33695
Country:Portugal
Oai:oai:ria.ua.pt:10773/33695
Description
Summary:In 2012, Google released the Dart language which, more recently, due to Flutter, has received a boost in popularity and is being often referred to as a full-stack language / ecosystem suitable for developing front-end and back-end solutions. However, aside from Flutter for mobile, Dart usage is still quite low when it comes to developing enterprise level solutions. In this dissertation, we tried to investigate the adequacy of using Dart to develop a full-stack solution with special focus on its back-end support. With that in mind, a typical scenario involving both a mobile and a web-supported front end, where both communicate with a back-end server via a REST endpoint, was established. For performance comparison, we deployed an equivalent back-end server developed using Spring Boot, a popular Java-based solution, which was used as reference. The main result was that a full-stack system can be developed with just a Dart / Flutter ecosystem and, in our scenario, this system’s performance surpassed Spring Boot’s. From a developer’s perspective, off-the-shelf Dart embedded asynchronous solutions (e.g., streams, Futures, etc.) are clearly an improvement over similar mechanisms in Java / Spring Boot due to avoiding typical Java solutions, namely asynchronous configurations, and annotations. However, despite some interesting projects arising, when excluding Google’s own developed packages/resources, most third-party packages are either using out-of-date dependencies due to compatibility issues or have been abandoned entirely – this had an impact during the development stage as it led to unplanned constraints when choosing packages and / or frameworks used.