Building Flutter apps with no backend?
It’s possible with the free & open-source @platform.
As developers, we have to make so many decisions when we start a new project:
What database should I use?
What is the best architecture to handle user data?
Where should I host it?
How much will it cost?
How do I protect that data?
Imagine a world where all of these considerations were taken care of for you.
Imagine a world where you could start writing code immediately and focus entirely on the features and functionality of the application.
Enter — the @platform — a free and open source technology written in Dart and Flutter by The @ Company. The @platform allows developers to build beautiful apps and brand new customer experiences on Flutter, and eliminates the need to build a backend for your application. User management, security, and data storage are core features of the platform, and enabled by default. And to make it even better, everything on the @platform is fully end-to-end encrypted. We believe that all applications on the internet should be built this way. It makes it easy on you as the developer, and provides the end consumer trust and peace of mind when using apps built on these principles.
This sounds great, but how does it work?
Behind the scenes, the @platform works differently than your typical application architecture, but it’s for a good reason. Apps on the @platform provide several unique advantages:
I will get more into each of these topics later, but for now let’s take a look at how it works in simple terms, and how it’s different.
Typical App Architecture on the Internet
In your typical architecture, data is centralized around the application, and your data is held on someone else’s servers. When developing with this model, we as developers are responsible for configuring the entire stack. Even if we use a tool to do some of the work for us, we are responsible for connecting and configuring them to meet our requirements. As a user, my information is all over the place, and I have to replicate my information for each application.
The @platform Architecture
The @platform follows a simple peer-to-peer model, using an @sign to represent a person or entity. For example, @alice or @nike. In this model, your devices (usually your smartphone or tablet) act as mini-servers and store all of your data. Each @sign has its own dedicated private server, called a secondary server, that syncs data across your devices and communicates with other @signs.
If you are sharing information to another person, you never send out or transfer that data to them, you will simply be giving access to the information on your servers to whomever you trust. Tomorrow, if you decide that the other person does not need access to it, you can simply revoke access, and the cached data on the other person’s phone gets removed.
We haven’t used the phrase “Central Database” thus far — because there isn’t one. Instead, you have your own “Personal Database.” The @platform makes use of hiveDB, which is written in Dart, where each device syncs with your secondary server to make sure all of your information is synchronized across all of your devices.
The best part of this is that the @platform is designed in a way such that developers don’t have to interact with these inner workings directly. Through careful abstraction, we’ve made @platform apps feel like any other app for both the developers and the people using the apps. Years of thinking and research has gone into making the app building process on the @platform as simple and intuitive as possible.
As stated in the @platform’s whitepaper, data is end-to-end encrypted. Your keys are only stored on your device, and thus encryption can only happen from your device. Your data is only available “in the clear” (unencrypted) on your local device or cached on the devices of people with whom you share the information. As everything is peer-to-peer, and data is only available on the edge, there is no centralized target, which provides additional security from denial of service attacks and large-scale data breach attempts.
True Data Ownership and Privacy
Another important thing to note from the whitepaper is that the same data is uniquely encrypted for each different @sign it’s shared to. This gives you true ownership of your data; when you choose to revoke access from someone else, their locally cached copy and the copy uniquely encrypted for them are both removed. This is a much deeper level of control for you, compared to application permissions. Oftentimes when we are sharing information across centralized applications, the business logic determines whether someone can or cannot access your data, whereas on the @platform your data is truly unavailable to others (by default). Of course, with true ownership and control over your data, you are also granted true privacy.
You may be wondering, “What is application hyperconnectivity?” Put simply, it is the ability to share your information between applications. Since all of your information on the @platform is stored in a single place, your information can be reused across all of your applications. The best example of this is in our at_contact and at_contacts_flutter packages, which, when implemented into your application, will allow people to reuse their contact list across all of their applications. Meaning, when you add a contact in app A, it will then be available to you in app B, and vice versa.
We can even take things one step further: the @buzz app is a stellar example of polymorphic data on the @platform. @buzz is like your contacts application, but with a twist. Rather than manually entering details for all of your contacts, and having to deal with duplicate contact entries from trying to sync all of your contacts over the cloud, you simply connect with someone through their @sign. In @buzz, they can create and share a specific persona with you. For example, I might want to share my work phone and email with colleagues, but my personal phone and a different email with friends. I can set up separate “work” and “friends” personas with each set of information, so when I connect with someone new, all I have to do is share the correct persona with that person. Better yet, if I want to share multiple personas, I can do that too! If I move or change my email address, I can update my information in the app, and my contacts have access to the new information and don’t have to make any edits themselves.
How do I get started?
Stay tuned for part 2, where we will go in depth on how to get started building Flutter apps on the @platform. In the meantime, you can follow our getting started guide, which will take you through the process of getting your own @sign and setting up your first @platform app!
To learn more join our fast growing Discord: https://discord.gg/nTwb3MrU7x
Follow us on Twitter: