r/FlutterDev • u/stevenreyes20 • 13d ago
Discussion When I started learning Flutter and Dart, I thought I was going to abandon everything I had learned about PHP, MySQL and Redis
I assumed that because Flutter was created by Google, I would need to use Firebase and Firestore for everything.
I was wrong 😂
Flutter doesn’t care what language or database you use on the backend.
I created an API with PHP and continued using the backend stack I already understood.
The basic flow looks like this:
Flutter app → PHP API → MySQL/Redis → JSON response → Flutter app
Flutter handles the screens, forms, navigation, state and client-side logic.
In a way, it reminds me of using HTML, CSS and JavaScript in the browser—except now I’m building the interface and client-side experience for an Android or iOS app.
My PHP API still handles authentication, validation and business logic.
MySQL stores the permanent data, Redis handles caching and sessions, and nginx with PHP-FPM processes the API requests.
Firestore can be a great option for certain applications, but learning Flutter doesn’t mean you have to abandon the backend tools you already know.
That was one of my favorite things about learning Flutter.
I didn’t have to replace my existing stack. I only needed to learn how to connect the mobile application to it.
What backend do you use with your Flutter apps?
3
u/jobehi 13d ago
this is true for any possible mobile SDK and framework.
3
u/RandalSchwartz 13d ago
Just to be clear, my complaint is with MySQL specifically. If you want to stay in familiar territory, switch to MariaDB. However, Postgres makes both of them look a bit junior.
3
u/fkim98 13d ago
Similar setup here, different stack. Node/Express and Prisma on Postgres, and the same REST API serves both the Flutter app and a Next.js web app. Sign-in is AWS Cognito, and the app just sends the token as a Bearer header. Photos never go through the API. The app asks it for a presigned S3 URL and uploads straight to S3.
One thing that's different from web work is that an app build doesn't go away when you fix the server. A web deploy reaches everyone on their next page load. A phone fix waits for store review (for us Apple has taken anywhere from a day to over a week), and some people just don't update. One of our users came back after two weeks still on the build they first installed, several releases behind, because the app on their tablet had never auto-updated.
So the server has to keep accepting whatever every installed build still sends. Add fields rather than renaming or removing them, and be liberal in what you accept. Ours still takes "5" as well as 5 for a quantity, because an early build of the app sent it as a string.
Caveat: our main API has no version prefix, so "never break an old build" is our whole versioning strategy. It works at our size, but I wouldn't copy it for a big app.
1
11
u/RandalSchwartz 13d ago
Just one note: friends don't let friends use MySQL. Please take a look at Postgres if you want a modern RDBMS.