The Ugly Truth of Flutter
Building an App from Scratch: Part 3
In Part 0 of this series, I expressed an intense interest in utilizing graph databases and thus GraphQL to manage the backend of my to-be social media app, Gotu. In Part 1, I provided a high-level overview of the advantages and trade-offs of using Flutter instead of a Javascript framework.
If I was working for a multi-million (billion?) dollar corporation that needed to churn out a safe product, it is beyond reasonable to go with the industry standard (again, something like React/React Native). I, however, am not doing that. If I haven’t hammered it in by now, Flutter is an emerging framework with its unique set of issues and advantages.
Let us consider the timeline of Python and some common packages for the language. Python had its initial release in 1991, and 1.0 wasn’t released until January 1994. NumPy’s initial release and 1.0 didn’t come until 2006. Matplotlib had its initial release in 2004, but didn’t hit 1.0 until 2010. SciPy’s initial release came out in 2001, but the package didn’t hit 1.0 until 2017.
If you haven’t gotten it yet: programming languages grow and mature and become standardized over time — sometimes, over the course of decades. If you look at the official Flutter documentation for state management solutions, it provides fourteen different options. Although, only about 5 have considerable merit. This is still a lot! Of course, this issue persists on in internal level: project organization, state management, etc.
These issues materialize with greater impact on an external level. That is, in the case of APIs. If you don’t know what an API (application programming interface) is, think of it as the way computers communicate. APIs are that fast, efficient level of communication between various software and services. E.g., the underlying code and protocols that lets you use your Facebook login for so many other services. Here is a page from Red Hat on the subject.
The issue of APIs is on the forefront of my mind since I have been taking my first deep-dive into understanding backend development. Initially my goal was to develop Gotu utilizing a graph database backend, which was to be interacted with via GraphQL. Perhaps I have been swayed by the controversial Stephen Wolfram into an occult love of graphs and hypergraphs, and likely the draw of a bleeding-edge tech drew me in. Realistically, I need to walk before I run.
My search for a graph backend led me to two candidates: Dgraph and Neo4j, currently two of the most popular graph database services.
There is technically a dart package that communicates with Dgraph and acts as a make-shift API (link), but as of this publication, this package has not been updated in over a year.
For the latter, there is the neo4driver Dart package. It has been updated as recently as two months ago, but seems to be only maintained by one person and does not have a significant following. I had high hopes for this project to be my solution, yet the package threw a persistent error regarding the version of Flutter being run.
I also considered AWS Neptune (Amazon Web Services’ graph database solution), which also technically has a Dart package (link), but at this point I had decided to stray to another solution.
Firebase
If you’ve even dipped a toe into the mobile app or web app development world, you’ve heard of Firebase. Firebase is Google’s real-time, cloud-based, JSON-based NoSQL super-soldier in the Backend as a Service (BaaS) battlefield.
Not only is there maintained, extensive support for adding Firebase to one’s Flutter application, there is official support for Flutter maintained by Firebase. (This is not totally shocking, given that Dart, Flutter, and Firebase are all Google products.) Firebase really is the total package, offering an array of analytics tools with a strong reputation for scalability. There are a plethora of articles and videos explaining the finer details of Firebase and why it’s such a dominant force in the development world, so I will not linger on a point already made.
To compare this shift to my initial goals of using a graph backend, let’s re-evaluate our priorities.
(1) I want a well-performing backend.
Graph databases are generally structurally well-regarded to suit the needs of a social media platform. Imagine the complex web of friends, comments, likes, messages, and other components that go into social media. It’s called a social network for a reason. Hell, Facebook was the entity that released GraphQL in 2015. Still, Gotu will likely never see over 100 users. The difference in performance between, say, Dgraph and Firebase will be negligible for my purposes.
(2) I want to learn how to build an app and gain industry knowledge.
Music students do not enter their first music theory course and immediate dive into Cage, Schoenberg, and Zappa. Bach, Mozart, and Beethoven are studied for a reason (although I do have a soft spot for both Cage and Zappa). Their music is excellent and sets the standard for the world of Western art music (i.e., “classical” music). Likewise, Firebase is a standard. I am still learning something useful, arguably more useful than a lesser-known graph-based solution.
Why settle for something I didn’t want?
A reader might still be wondering something comparable to:
But why settle for Firebase? You wanted a graph database solution. You were forced into something else because it was the arguably easiest solution that Flutter can offer. Why not just use a JavaScript framework? What’s the benefit of taking a chance?
An artsier version of myself would harken to a line from Lin Manuel-Miranda’s Non-Stop (from Hamilton). I’ll be more direct — taking a chance on a yet-proven project is a balance of benefits and detriments. Of course, fumbling through life with a “no regerts” mentality is dangerous for the individual and those around them (either in a literal sense or a professional one). Yet, a life spend in the safety of academic and industrial standards scarcely rewards the explorative nature of the mind. Let’s imagine two scenarios for Flutter in the coming years.
Case 1: Flutter lives on and becomes an industry standard.
It’s no overstatement that Flutter has a significant foothold in the mobile application world. From the Flutter application showcase, Google Pay, ByteDance, eBay, and Tencent stand out as titans. The conclusion here should not be shocking — if such a thing happens, of course it will have been worth my time to get experience with the Flutter framework. Five years down the road, I will have five years’ experience with a dominating mobile application development kit.
Case 2: Flutter dies.
Of course, this is the less preferred option. Still, it is naïve to think that anything programming language will be mainstream forever (see Fortran, Visual Basic, Objective-C, and PHP)*. Worse yet, there are many, many languages that never truly get off the ground. For Flutter, takeoff has been successful, but there are still mountains taller than our current altitude. In this case, “death” more accurately analogs something of technological stagnation. Still, suppose Flutter functionally dies in the next five years. Will I have wasted my time learning a useless language? Absolutely not. Were all Objective-C developers kicked to the curb in place of up-and-coming Swift developers? No. Indeed, in many cases these two types of developers were one and the same; this is one bias. However, “knowing” a programming language (whatever that really means) is half the battle, if that. What is truly desirable is industry knowledge. Let’s consider again the Swift example. Sure, in 2014, Swift might have been just as new to a veteran Objective-C dev as it was to a newly minted college graduate. However, the Objective-C developer already has experience in the app development field. As we will touch on later, someone in this position has a pre-existing knowledge of databases, SQL/NoSQL, APIs for common services such as Google maps, financial institutions, etc., and a qualitative feeling for what is expected in the field.
*Yes, I know Fortran is still used extensively in scientific computing, many websites still use PHP, and Objective-C is still technically supported by Apple. The point is, each of the four examples I provided were among the most used programming languages at some point, but have now fallen out of the limelight.
What’s next?
Maybe manager wanna write goddamn login page himself…
- Jonathan Coulton, Code Monkey (2006)
Now that a cobblestone path has finally emerged from the weedy overgrowth of the cloud database woods, it is time to take our first steps. Next time, I will not be returning to the UI that I had built in the last part. Instead, I will be working on a simple login page application. There will be baby steps; that is, starting with a button that sends some sort of data to Firebase.
I would also like to steady my hand in the presentation of my project. Look forward to an initial commit (and many, many subsequent commits) to the project on my github.
Next (Coming soon!)
About the Author
Thanks so much for reading! I’m Garrett — an applied mathematics graduate student, music theory enthusiast, and hobbyist author. My research focuses on computational fluid dynamics, but I am also interested in PDEs in general, graph/hypergraph theory, geometric algebra, cellular automata, and many other fields of STEM.
This series documentaries my attempted transition from the world of academic scientific computing to the realm of full-stack application development.
Feel free to reach out, I love talking to people from all backgrounds, and hopefully each of us can learn something new in the process. You can find me via my personal page:
