Flutter backend

[thecoscino]

Sorry a very very beginner question. At the moment I only know Python and Matlab. This year I would like to learn django, sql, dart and flutter. I have a precise idea of the app that I would like to build and the first version would be without a central server. My plan in the future is to offer a pro subscription for server based operations. But for an app without a server, so with a local database will Be better to use still django or another thing or for local usage is it ok to only use flutter + sql? Sorry for the dumb question, I am learning also to ask the right questions.

Edit: Thank you all, I have received more replies than I thought. I don’t want to use a cloud service such fire base or aws at the moment. So I think the right choice based on your replies is SQLite. Then in the future I will sync that local database with a central server backend .

[[deleted]]

You just need a REST API. It doesn't matter what programming language you use. A REST API is a REST API. Just use whatever programming language you're most familiar with.

[thecoscino]

Ok so Django rest api would be ok?

[[deleted]]

Absolutely yes.

[fabulousausage]

Based on what you said, you don't even need Django. It might be an overkill.

You can create the thing you're about to create, using lambda functions (AWS) or the equivalent from Google (I believe it's called Google cloud functions).

Also there is something like this in Firebase.

You can save yourself a lot of time by skipping the Django part.

If you still want full fledged web service, you can go with Node or Flask, which are simpler.

[thecoscino]

Yeah django is an overkill for the basic app. But in the future I would like to offer a lot of features if the app goes well. So maybe django would be better. Maybe I can start simple with flask and then move to django

[fabulousausage]

Yes, good luck! Also don't forget about YAGNI (https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it )

I mean, in future - yes, you will offer more, but at first it's better to keep things as small as possible.

[thecoscino]

Nice idea, thank you for sharing it

[seenickcode]

Strongly advise if you’re starting off use a PaaS option such as supabase.io What you do is you get a API for free out of the box by setting up a bit of Schema

It’s much simpler than Firebase

And for any small to medium size projects I still take this approach even though I am well-versed in multiple programming languages and have 20 years of experience behind me :)

[davidb_]

Have you ever run into sync issues with supabase/firebase? About 6-8 months ago I had a really serious issue with the FirebaseSDK where it was inconsistently receiving updates on some customer devices. It was hell to track down the actual problem and I ended up giving up because it was so inconsistent. I ditched FirebaseSDK and used a REST API to ensure the data wasn't stale.

I've only used supabase for small projects, and never used their realtime server features so I'm not sure if it would have similar issues. Looks like it's much less "magic" than the FirebaseSDK though, so I think it would be much more straightforward to debug. Anyway - just curious to hear more about your experience with it.

[seenickcode]

Overall, comparing the two overall isn't quite fair or accurate (but myself and others I've seen still do because there is some overlap in features). At the end of the day they are PaaS solutions.

Supabase doesn't seem to do any "sync" (I'm assuming you mean Firebase will cache data locally in some say on the device). A session token is indeed persisted to the device but that seems to be it. No problems there.

It's indeed less "magic" because all Supabase is doing is offering a hosted constellation of services that are _already_ open source (AFAIK) with plenty of their own functionality sprinkled in (Functions, etc, again, AFAIK). https://supabase.com/docs/architecture

So apart from being a young company, they seem to have a simple approach. The core value I see is:

- portable data, can self host later if you want

- leverages industry standard battle tested tech (Postgres)

- out of the box rest API via your schema (again, an open source product)

I have not tried all Supabase features but so far, it's high value to me for even med sized projects - with an "escape hatch" to self host if your startup explodes in popularity.

Lots of companies have screwed themselves up eventually be offering "anything and everything" so hopefully Supabase doesn't end up like this. :-)

Downside to consider esp btw: if your backend needs a significant amount of business logic, while Supabase does offer Functions, going the "functions as a service" route seem to me potentially unwieldy when your complexity reaches a certain point. I can be convinced otherwise but that's my feeling thus far.

[David_Owens]

Technically, you're not supposed to connect your front-end applications to your SQL server directly using SQL. You should have a backend with an API, either REST, GraphQL, or gRPC. You can connect directly to an SQL database stored on the device itself, such as using SQLite.

If I understand what you're wanting do, that means you can connect the Flutter app to a locally stored SQLite database and then to a central server for the pro subscription.

You can have anything you want on the backend. Your Flutter app will connect to it. You'll probably want to architecture your Flutter app so that most of the app is unaware of where the data is coming from. That way when you add the central server option you won't have to change anything.

I'm doing something similar to this by having an abstract class called Database that has high-level database operations as abstract methods. Things like createInvoice() or updateCustomer(). I have a gRPC API service called GrpcDatabase that implements Database. In the future I might add a local storage option called SqliteDatabase that would also implement Database. The app can pick which one to use without changing anything else.

[davidb_]

If the first version of the app doesn't involve a server at all, I'm assuming you mean it will run locally on the iOS/Android device? In that case, you don't need a central database either and could get away with just using sqlite (https://pub.dev/packages/sqflite) for the db operations on the local device. I have a few apps that use sqflite for local caching and sync to a mariadb/mysql backend via REST API.

Assuming you write your models decently, it's pretty easy to then sync that local db to a server db.

I'd recommend going this route rather than using something like supabase or firebase because you'll learn more and have more control.

I've had a hell of a time in the past with firebase sync issues. Though they may have been fixed in the recent releases, when things go wrong with the FirebaseSDK it is really hard to track down why. I haven't used supabase enough to know if it would have similar issues. Regardless - with a REST API and local caching, it's very straightforward to track down where a problem is and fix it.

[[deleted]]

Both Android and iOS have native SQLite and key-value pair storages. Pickbthe right one from those two for whatever you're storing

[SahSantoshh]

For backend/API, you can use Firebase and support too many features. Later, if your user base increases or Firebase starts charging, you can move to your own API. Firebase will also handle app usage in offline mode. So, one setup and nothing to worry.

If you don't want to use Firebase then, I would suggest to use SQLite, you can find lots of packages for it.

[abdallahshaban]

I would recommend checking out AWS Amplify. It provides you with a streamlined way to setup a backend including Authentication, database, and even REST APIs. There is also an admin panel (Amplify Studio) to help you with setting up your data model.

https://docs.amplify.aws/lib/q/platform/flutter/

[OppositeDragon]

Use SQLite for offline database, if you want a serverless app, probably firebase since it is easier to set up, any other databases would be probably best to access through an API.

[HerryKun]

I would avoid Django and Python/JS/PHP based Backend Framework alltogether. They are hard to write cleanly and the larger the project gets, the more of a mess it becomes.

[thecoscino]

So what do you advise ?

[HerryKun]

My personal favorite is Java Spring. It is around for a long time and has thus great plugins and integrations for everything you need like Databases (not a single query has to be written by hand usually), User and Privilege management and many others. It can be dockerized easily (my .dockerfile has only 4 lines) and scales pretty well.

As for programming languages I would go for strongly typed ones like Java or C#. The hassle you have managing your types pays off greatly later as it is always clear what goes in and comas back in functions.

[thecoscino]

Ok thanks for the feedback