Flutter use Stream or Future?

Question

I'm using Firestore database to store a list of objects. To retrieve them I use the Stream provided by the Firestore package, like this:

 class FirestoreApi implements Api {

  FirestoreApi._();
  static final instance = FirestoreApi._();

  @override
  Stream<List<Job>> getJobList() {
    final path = "users/myUserId/jobs";
    final reference = Firestore.instance.collection(path);
    final snapshots = reference.snapshots();

    return snapshots.map((snapshot) => snapshot.documents.map(
      (snapshot) => Job(
        id: snapshot.data['uid'],
      name: snapshot.data['name']
     ),
    ).toList());
  }
}

It implements an abstract class:

abstract class Api {
  Stream<List<Job>> getJobList();
}

In my Repository class I call it like this:

class Repository {
  final FirestoreApi _firestoreApi = FirestoreApi.instance;

  Stream<List<job>> getJobList() => _firestoreApi.getJobList();
}

Then in my BloC I call the Repository:

class JobBloc {

  final _repository = new Repository();

  Stream<List<Job>> getJobList() {
    try {
      return _repository.getJobList();
    } catch (e) {
      rethrow;
    } finally {}
  }
}

And finally here is how I use it in my Widget:

Widget _buildBody(BuildContext context) {
  final JobBloc _jobBloc = Provider.of<JobBloc>(context);

  return StreamBuilder<List<Job>>(
  stream: _jobBloc.getJobList(),
  builder: (BuildContext context, AsyncSnapshot<List<Job>> snapshot) {
    if (snapshot.hasData) {
      return RefreshIndicator(
        child: JobList(snapshot.data),
        onRefresh: () => _jobBloc.refreshJobList(),
      );
    } else {
      if(snapshot.connectionState == ConnectionState.waiting) {
        return Center(child: CircularProgressIndicator());
      } else {
        return Center(child: Text("No data"));
      }

    }
  },
);
 }

Until here everything works great and my Widget gets updated in real time when something is changed in the Firestore database.

But now I want to go one step further. Lets say that maybe in the future I need to change my api implementation and use a REST api instead of Firestore. I want that my code is prepared for that.

In that case, all the getJobList() methods should return a Future<List<Job>> since the API will not return a Stream (I don't know if that's possible).

I would have another API class like this that now returns Future<List<Job>>:

class RestApi implements Api {

 RestApi._();
 static final instance = RestApi._();

 @override
 Future<List<Job>> getJobList() {
   //TODO: my rest api implementation
 }
}

So the API abstract class would be modified like this:

abstract class Api {
  Future<List<Job>> getJobList();
}

Here the updated Repository:

class Repository {
  final RestApi _restApi = RestApi.instance;

  Future<List<job>> getJobList() => _restApi.getJobList();
}

And finally in my BloC I would sink the list returned by the API in a StreamController like this:

class JobBloc {
  final StreamController _jobController = StreamController<List<Job>>.broadcast();

  // retrieve data from stream
  Stream<List<Job>> get jobList => _jobController.stream;

  Future<List<Job>> getJobList() async {
    try {
      _jobController.sink.add(await _repository.getJobList());
    } catch (e) {
      rethrow;
    } finally {}
 }
}

Now the question: I really like that Firestore returns a Stream, it makes my app to be updated in real time. But on the other hand, I would like that my architecture is consistent.

Since I cannot make my REST api to return a Stream, I think the only way possible would be converting the Firebase Stream to a Future but then I would loose the real-time update feature.

Something like this:

class FirestoreApi implements Api {

   FirestoreApi._();
   static final instance = FirestoreApi._();

    @override
    Future<List<Job>> getJobList() async {
      final path = "users/myUserId/jobs";
      final reference = Firestore.instance.collection(path);
      final snapshots = reference.snapshots();

    Stream<List<Job>> jobs = snapshots.map((snapshot) => snapshot.documents.map(
        (snapshot) => Job(
          id: snapshot.data['uid'],
          name: snapshot.data['name'],
        ),
       ).toList());

      List<Job> future = await jobs.first;
      return future;

     }
   }

Until now what I've researched is that using the Future will return only one response, so I will lose the real-time functionality.

I would like to know if loosing the real-time feature would be worthy just to make the architecture consistent or if there is a better approach.

Thanks in advance, any ideas or suggestion will be appreciated.

EDIT: Thanks a lot for your comments, I really appreciate them. I actually don't know which one should be marked as accepted answer since all of them have helped me a lot so I decided to give a positive vote to all of you. If anyone doesn't agree with that or this is not the right behaviour in Stackoverflow please let me know

Starinsky

FYI backtick quotes are not used for general text emphasis on Stack Overflow. They're used for snippets of code. – Mckeon

Thanks @DougStevenson I've edited my code trying to follow your suggestion – Starinsky

Answer 1

First of all, in my opinion, firebase is not designed to back up a mature project. In the end, you'll end up with a REST api backing up your app. It's true that, you might also end up using both but for different purposes. So i think you should think about firebase as a tool for MVP/proof of concept. I know that Firebase is cool and works well, etc. but the costs are not feasible for a final product.

Now, nobody says that you can't have a REST client implementation that will return a Stream. Check out this Stream.fromFuture(theFuture). You can think of the REST api like a stream that emits only one event (Rx equivalent: Single)

I would also advise to be careful with the real time update feature provided by Firebase, if you transition to a full REST api, you won't be able to do a real time update because REST doesn't work like that. Firebase is using Sockets for communication (if I remember correctly).

Kristianson

This kind of answer's always priceless – Joselyn

Can someone explain this, "I know that Firebase is cool and works well, etc. but the costs are not feasible for a final product."? He makes it sound like "real" apps shouldn't use Firebase, but aren't there many apps that use it? – Tingey

@Tingey I'm not aware of any production app, that has more than 100k users that uses Firebase as a backend. It's quite hard to do complex operations on firebase, and after a point the firebase will charge you a lot. Just so you know, real time database provided by firebase supports only 100 concurrent connections, which in simple words would be 100 users at any time can fetch some info, the others have to wait. – Kristianson

I'm not sure why someone would use the Realtime Database that only supports 100. It sounds like Firestore allows much more. I've read anywhere from 100k to 1M. Do you have an example of a complex operation that is fairly simple to do w/o Firebase and is difficult to do w/ Firebase? – Tingey

Answer 2

I recommended use the Future way, if you take a break and compare the two codes, with the Future way you need to write more, but the architecture is more clean, strong and scalable. In my experience, that's the right way to do good things. Great work

Jaleesa

Answer 3

You can also include both methods in the api / repository, and either retrieve a Future or listen to the Stream in the bloc depending on what you want to do. I don't think you need to worry about violating the consistency of REST by also having a method that returns a stream. There is no better way to tap into the real-time functionality of Firestore than to use a stream like you described.

But to just return a Future, you don't have to go through a stream, you can just await a CollectionReference's getDocuments(), something like this:

class FirestoreApi implements Api {

FirestoreApi._();
static final instance = FirestoreApi._();

CollectionReference jobsReference = Firestore.instance.collection("users/myUserId/jobs");

@override
Future<List<Job>> getJobList() async {
  QuerySnapshot query = await jobsReference.getDocuments();

  List<Job> jobs = query.documents.map((document) => Job(
      id: document.data['uid'],
      name: document.data['name'],
   )).toList();

  return jobs;

 }
}

Humanoid

Answer 4

It all depends on your app I think. If real time update is an important feature that effects user experience a lot, stick with the Firebase data streams. If real time updates are not a must, you can get data once using Futures. An alternative to Firebase for real time data updates could be GraphQL subscriptions. I would recommend you to check out Hasura for quick implementation of GraphQL API.

Balaam

Answer 5

It's a good question.

Firestore vs REST API will result in different APIs (Stream vs Future).

Making the code generic won't work here. As you said:

• Stream-based APIs will be realtime
• Future-based APIs will not

Even the UX would be different.

• In the Stream version, you don't need a refresh indicator.
• In the Future version, you can reload the data with pull-to-refresh.

I would not recommend to future-proof your code in this case.

If Firestore works well for you, use Streams in all your APIs.

Only if/when you decide to move to a REST API, then you can convert all your APIs (and UX) to use Futures.

Giving up realtime capabilities upfront doesn't seem worth it.

Segregationist