Forem: njoee

Spring & Ribbon In Kubernetes

njoee — Fri, 28 Apr 2023 12:22:33 +0000

Hi, at this moment I was interest to write something about deploying Springboot based microservices to Kubernetes environment.

So the idea is that I want to have sets of microservices spring boot based, and deployed to kubernetes as the picture bellow:

Basically we are going to have 2 microservices

The client can call these methods
-/users/v1/save --> Create User & Account
-/users/v1/all --> Get Users data
-/account/v1/all --> Get Accounts data
-/account/v1/save --> Create Account data

While user created, user_services will also call account_service to create the account

for doing this. the problems will be lay on

how user_services can call to account_services while account > service can be deployed on multiple instance and sets.
how can we make N Replicas of account_services and
User_Services can understand which account_services to
consumed
as the image bellow:

that is where the The discovery client and The Ribbon Client Load Balancing come into play.

#1 The YAML

Here is the Dependencies you should to take a look.
These are the dependencies for spring cloud kubernetes.
all the microservices must be able to be observe by other services by making the microservices discoverable by client.
to do so you'll need bellow dependencies

<dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-openfeign</artifactId>
            <version>4.0.1</version>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-kubernetes-ribbon</artifactId>
        </dependency>

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-kubernetes-all</artifactId>
        </dependency>

also you need this dependencies, for later on used by the ingress for liveProb and healthProb mechanism.

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

#2 The Discovery Client & Feign Clients

now, we need to make our microservices discoverable by other microservices. with spring cloud after we put the dependencies above, we can do this in our application.java

@SpringBootApplication
@EnableFeignClients
@EnableDiscoveryClient
public class GIDUsersApplicationServices {

    public static void main(String[] args) {
        SpringApplication.run(GIDUsersApplicationServices.class, args);
    }

    @Bean
    public TimedAspect timedAspect(MeterRegistry registry) {
        return new TimedAspect(registry);
    }

}

#3 The Business Logic

remember in our case we will create account during user creation on user_services. here are the code logic

@Override
    public Resources<UserDTO> saveUser(User requestData) {
        Resources<UserDTO> serviceResult = new Resources<UserDTO>();
        serviceResult.throwResponseWithCode("99", "failed to save user", null);

        UserModel userData = this.userDAO.addUser(requestData.getUserName());

        if (userData != null) {
            AccountCreation requestAccountCreation = new AccountCreation();
            requestAccountCreation.setUserId(userData.getUserId());
            requestAccountCreation.setAmount("10000");

            // ## Call request data to account services
            System.out.println("request data" + requestAccountCreation.toString());
            Resources<AccountDTO> createAccountResult = this.serviceProxy.saveUser(requestAccountCreation);
            System.out.println("response data" + createAccountResult.toString());
            // ## Call request data to account services

            if (!createAccountResult.getResponseCode().equals(ApplicationConstant.GENERAL_SUCCESS_CODE)) {
                return serviceResult.throwResponseWithCode("99", "Failed to save user", null);
            }
            UserDTO user = new UserDTO();
            user.setUser(userData);

            return serviceResult.throwSucceedResponse(user);
        } else {
            UserDTO responseOBject = new UserDTO();
            responseOBject.setErrorModel(new ErrorModel("ini error"));
            return serviceResult.throwResponseWithCode("99", "Failed to save user", responseOBject);
        }
    }

now lets zoom carefully into this line
this.serviceProxy.saveAccount

#4 The FeignClient for saveAccount

now lets take a look into the saveAccount Method bellow:

// @FeignClient(value = "account-services", url = "http://34.128.121.224:81/account")
@FeignClient(name = "gid-account-service")
public interface IAccountServicesProxy {

    @RequestMapping(method = RequestMethod.POST, value = "/account/v1/save")
    public Resources<AccountDTO> saveAccount(AccountCreation requestData);

}

as you can see, instead of using
@FeignClient(value = "account-services", url = "http://34.128.121.224:81/account") to point out the account services by its ipAddress

we can use this
@FeignClient(name = "gid-account-service") and get the available ipAddress from kubernetes Services.

as mention here in spring cloud, that

This project provides an implementation of Discovery Client for Kubernetes. This allows you to query Kubernetes endpoints (see services) by name. A service is typically exposed by the Kubernetes API server as a collection of endpoints which represent http, https addresses that a client can access from a Spring Boot application running as a pod

now we fetch all the pods ipAddress from the kubernetes services so we don't need to to put the ip address in our code anymore and let the services get the destination ip from kubernetes services. this discovery concept is similar with usage of eureka

So basically we are no longer need eureka when we use kubernetes.

Notes : in order to make this possible you have to make sure that the services name in here

spring.application.name=gid-account-service same as services
name you put on your k8s-deployment

IMPORTANT : Makesure your spring.application.name equal with your Kuberenetes Services Name

apiVersion: apps/v1
kind: Deployment # Kubernetes resource kind we are creating
metadata:
  name: gid-account-service # Required to be the same as spring config services name
  namespace: default

and you also need to make sure that you add this on your application properties, in order to enable the services become discoverable and the client load balancing on.

spring.cloud.kubernetes.discovery.enabled=true
spring.cloud.kubernetes.loadbalancer.mode=service

now we all sets. move to the deployment.

#5 The Deployment to Kubernetes.

before we go to the deployment process. make sure that you have

PostgreeDB Instance Ready to use. since the services need database
GKE Clusters
Install gcloud components
Connect to your Clusters

now here is the k8s-deployment for user_services

apiVersion: apps/v1
kind: Deployment # Kubernetes resource kind we are creating
metadata:
  name: gid-user-service
  namespace: bcad-testing-env
spec:
  selector:
    matchLabels:
      app: gid-user-service
  replicas: 2 # Number of replicas that will be created for this deployment
  template:
    metadata:
      labels:
        app: gid-user-service
    spec:
      containers:
        - name: gid-user-service
          image: noveriojoee/user_services:v0.0.6-staging.8 # Image that will be used to containers in the cluster
          imagePullPolicy: IfNotPresent
          # Configure the readiness probe
          livenessProbe:
            initialDelaySeconds: 90
            timeoutSeconds: 30
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 3
            httpGet:
              path: /actuator/health/liveness
              port: 8201
          readinessProbe:
            initialDelaySeconds: 60
            timeoutSeconds: 30
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 3
            httpGet:
              path: /actuator/health/readiness
              port: 8201
          ports:
            - containerPort: 8201 # The port that the container is running on in the cluster


---
#THIS IS SERVICES AS CONSUME BY INGRESS
apiVersion: v1
kind: Service
metadata:
  name: gid-user-service
  namespace: bcad-testing-env
  labels:
    app: gid-user-service
spec:
  selector:
    app: gid-user-service
  ports:
    - port: 8207
      protocol: TCP
      targetPort: 8201
  type: NodePort

and here is the k8s-deployment for account_services

apiVersion: apps/v1
kind: Deployment # Kubernetes resource kind we are creating
metadata:
  name: gid-account-service # Required to be the same as spring config services name
  namespace: default
spec:
  selector:
    matchLabels:
      app: gid-account-service
  replicas: 3 # Number of replicas that will be created for this deployment
  template:
    metadata:
      labels:
        app: gid-account-service
    spec:
      containers:
        - name: gid-account-services-pods
          image: noveriojoee/account_services:v0.0.3-staging.5 # Image that will be used to containers in the cluster
          imagePullPolicy: IfNotPresent
          # Configure the readiness probe
          livenessProbe:
            initialDelaySeconds: 90
            timeoutSeconds: 30
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 3
            httpGet:
              path: /actuator/health/liveness
              port: 8202
          readinessProbe:
            initialDelaySeconds: 60
            timeoutSeconds: 30
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 3
            httpGet:
              path: /actuator/health/readiness
              port: 8202
          ports:
            - containerPort: 8202 # The port that the container is running on in the cluster


---
# #THIS IS SERVICES AS CONSUME BY INGRESS
apiVersion: v1
kind: Service
metadata:
  name: gid-account-service
  namespace: default
  labels:
    app: gid-account-service
spec:
  selector:
    app: gid-account-service
  ports:
    - port: 8206
      protocol: TCP
      targetPort: 8202
  type: NodePort

by this deployment script we will have 2 sets of user_services and 3 sets of account_services

now lets exposed this to public via Ingress as our api gateway
and use GCE as the ingress controller.
read here for GCE vs NGINX Controller

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gid-user-services-ingress
  namespace: default
  annotations:
    kubernetes.io/ingress.class: "gce" #REF -> https://medium.com/@glen.yu/nginx-ingress-or-gke-ingress-d87dd9db504c
    kubernetes.io/ingress.allow-http: "true"
    servers.com/ingress.load-balancer-healthcheck-path: "/actuator/health"
    #kubernetes.io/ingress.global-static-ip-name: gid-public-ip #REF -> Create PUBLIC STATIC IP AND IMPLEMENT TO YOUR INGRESS USING GCLOUDCONTROLLER
spec:
  # defaultBackend:
  #   service:
  #     name: gid-user-service
  #     port:
  #       number: 8207
  rules:
  - http:
      paths:
      - path: /* #<-- can be anything. considered as default
        pathType: ImplementationSpecific
        backend:
          service:
            name: gid-user-service
            port:
              number: 8207
      - path: /account/* # <-- Follow your controller request path
        pathType: ImplementationSpecific
        backend:
          service:
            name: gid-account-service
            port:
              number: 8206

by above deployment scripts now we have this.

#6 Permission

in order to ribbon be able to fetch api list ip from the namespaces you can use RBAC or you can just give the admin permission with this command

kubectl create clusterrolebinding default-pod --clusterrole cluster-admin --serviceaccount=<namespace>:default

#7. The testing

after we deploy the services and ingress now lets try to hit the api through ingress.

first

lets try Kubectl get ing -A it will show all of your ingress

now you can start calling the api with public ip 34.107.131.195

and if you take a look deeper on your ingress description using kubectl describe ing gid-user-services-ingress

you'll see that default request will be routed to user_services and all request on [ip_address]/account will be route to account_services.

Happy Trying :D

References :

Flutter How To Use Injectable

njoee — Sat, 13 Aug 2022 04:34:00 +0000

hi, before we start, this article are continue from preivous post regarding flutter mvvm using provider, injectable, and freeze

MVVM Part 1
MVVM Part 2
The Code Project Is Here...

this article will focused on how to implement the injectable step by step...

now.. Injectable, are the Dependency Injection component that allow us to register an object to Dependency Injection through Annotation, instead of registering dependency with bellow approach

getIt.registerSingleton<TaskRepositoryImpl>(TaskRepositoryImpl());
getIt.registerLazySingleton<MainScreenViewModel>(() =>MainScreenViewModel());

we can simply put annotation on each class declaration of TaskRepositoryImpl and MainScreenViewModel like this

@singleton 
class TaskRepositoryImpl implements ITaskRepository{
  final String baseUrl = "run.mocky.io";

  ... 
}

@injectable
class MainScreenViewModel extends BaseViewModel {
  List<TaskModel>? _tasksData;

  final ITaskRepository _taskRepository = getIt<TaskRepositoryImpl>();

  ...
}

now in our case of WhatToDoApp
Remember This image?
we'd like to have a singleton Repository and late assign of ViewModel layer... so we declare the TaskRepository this way :

@singleton 
class TaskRepositoryImpl implements ITaskRepository{
  final String baseUrl = "run.mocky.io";

  ... 
}

and when we need to use it in the viewmodel we can use it this way

@injectable
class MainScreenViewModel extends BaseViewModel {
  List<TaskModel>? _tasksData;

//=== THIS WAY ===//
  final ITaskRepository _taskRepository = getIt<TaskRepositoryImpl>();

  ...
}

easy right?

no in order to implement this style, we need to import a couple things into our pubspec.yaml

dependencies:
  flutter:
    sdk: flutter
  injectable: ^1.5.3
  get_it: ^7.2.0
dev_dependencies:
  # add the generator to your dev_dependencies
  injectable_generator: ^1.5.4
  # add build runner if not already added
  build_runner: ^2.2.0

remember, everytime we declare class with @Injectable or @Singleton annotation, the injectable component actually will generating file that contain a registration to GetIt like bellow:

_i1.GetIt $initGetIt(_i1.GetIt get,
    {String? environment, _i2.EnvironmentFilter? environmentFilter}) {
  final gh = _i2.GetItHelper(get, environment, environmentFilter);
  gh.factory<_i3.MainScreenViewModel>(() => _i3.MainScreenViewModel());
  gh.singleton<_i4.TaskRepositoryImpl>(_i4.TaskRepositoryImpl());
  return get;

in order for injectable generating file content like above, you have to create some new file in my case it called Setup.dart
and the content is like this..

import 'package:get_it/get_it.dart';
import 'package:injectable/injectable.dart';
import 'package:what_to_do_app/Setup.config.dart';


final getIt = GetIt.instance;  

@InjectableInit(  
  initializerName: r'$initGetIt', // default  
  preferRelativeImports: true, // default  
  asExtension: false, // default  
)  

@InjectableInit(generateForDir: ['test'])  
void configureDependencies() => $initGetIt(getIt);

after we declare the Setup.dart above, we can run command

flutter packages pub run build_runner build --delete-conflicting-outputs

then it will generating file called Setup.config.dart. then that's it.. your Dependency Injection are now ready to serve you.. CHEERS!!!..

Ref:
Injectable
GetIt

Flutter How To Use Freeze

njoee — Sat, 13 Aug 2022 04:33:00 +0000

hi, before we start, this article are continue from preivous post regarding flutter mvvm using provider, injectable, and freeze
MVVM Part 1
MVVM Part 2
The Code Project Is Here...

this article will focused on how to implement the freeze step by step.

Now, How to Use The Freezed.

first.. on your pubspec.yaml on the dependencies sections you have to install (please ignore the version, use the latest one instead)

dependencies:
  flutter:
    sdk: flutter
  freezed: ^2.1.0+1
  freezed_annotation: ^2.1.0

and on the dev_dependencies sections you have to install

dev_dependencies:
  build_runner: ^2.2.0 //Generating implementation code
  flutter_test:
    sdk: flutter
  json_serializable: ^6.3.1 //Make serializable object(to/from) json

and here is the sample of the code

import 'package:freezed_annotation/freezed_annotation.dart';
part 'task_model.freezed.dart';
part 'task_model.g.dart';

@freezed
class TaskModel with _$TaskModel {
  factory TaskModel({
    required final String title,
    required final String description,
    @Default(false) bool isDone,
  }) = _TaskModel;

  factory TaskModel.fromJson(Map<String, dynamic> json) =>
      _$TaskModelFromJson(json);
}

now lets break it into a pieces,

Take a look at How The Class Constructed

@freezed
//This _$TaskModel is not autoGenerated you have to construct
//it manually using this format _${{ClassName}}
class TaskModel with _$TaskModel {
//for this section, you just have to follow these line
/* using this format
  factory {{ClassName}}({
   Declare all the fields here..
  }) = _{{ClassName}}
*/
  factory TaskModel({
    required final String title,
    required final String description,
    @Default(false) bool isDone,
  }) = _TaskModel;

//Allow your object to be serializable. can do mutation
//fromJson or toJson.
  factory TaskModel.fromJson(Map<String, dynamic> json) =>
      _$TaskModelFromJson(json);
//this Factory fromJson method is not autogenerated
// so you have to declare it manually with thisFormat
//  factory {{ClassName}}.fromJson(Map<String, dynamic> json) =>
//      _${{ClassName}}FromJson(json);


}

up until here.. your code will be RED everywhere.. haha dont worry take a look at the import

Take a look at the import

to be able to use @freezed or @unfreezed you have to import this

import 'package:freezed_annotation/freezed_annotation.dart';

and then you have to import this

part 'task_model.freezed.dart';
//this import can be very depend on the class name
//so the format will be
//part '{{className}}.freezed.dart';

this import will allow you to have the immutable or mutable ability of this model.

come to the next one.
you have to import this

part 'task_model.g.dart';
//this import are important because it makes your object are serializable.
//see the fromJson method in code above. without this import it will not run

up until here.. your code will be RED everywhere.. haha dont worry take a look at the code generation..

Lets generate the code.

before we go, make sure you already adjust your pubspec.yaml as the first section of this article already mentioned.

now lets ask the build runner to make the implementation class of our model...

make sure you already do flutter pub get to install the pubspec.yaml

then you run this command

flutter pub run build_runner build --delete-conflicting-outputs

and after it run it supposed to generate the implementation file like this.

and here we go.. now you can take a look at your model class, there will be no red anymore.

haha thanks!!..

MVVM With Flutter (Part2){Freeze}

njoee — Thu, 11 Aug 2022 09:53:00 +0000

well, before go to this, please take a look at the previous post first MVVM With Flutter (Part1)

Back again!,

continue from previous post, in this post we will focus to Repositories and Model Layer.

Remember We would like to create our codebaseline this way:

so now we are going we have this already from the previous post.

now we are going to focus on this layer, by using API as our datasource.

in our cases, we have
MainScreen (View)
MainScreenViewModel (ViewModel)
TaskModel (Model)
and we have
ITaskRepository (Repositorires)
as a tools for (ViewModel) to fetch (Model)..

And Maybe Later On you have XModel can be manage by XRepository and so on...

Lets Take A look into code,

First, you'll create an abstract class like this acting like an interface

abstract class ITaskRepository{
  Future<List<TaskModel>?> getAllTask();
  //and all the method regarding add, update, delet, getById   etc..
}

and now see the implementation code

@singleton 
class TaskRepositoryImpl implements ITaskRepository{
  final String baseUrl = "run.mocky.io";

  @override
  Future<List<TaskModel>?> getAllTask() async{
    var url = Uri.https(baseUrl, "/v3/6bb86bda-08f1-4d7d-99c6-a975bc1201e0");
    final response = await networking.get(url);
    final responseBody = GetTaskDTO.fromJson(jsonDecode(utf8.decode(response.bodyBytes)) as Map<String,dynamic>);
    return responseBody.tasks;
  }
}

from the code above, as you can see. we register the TaskRepositoryImpl into our Dependency Injection and provide it as a Singleton Object whenever we need it.

also, we have method getAlltask() responsible to fetch all the task that user have, meaning return list of TaskModel fetched from the API which we are using http_package

as you can see, we convert all the json response directly into object in this line of code, from this json object

{
  "tasks": [
    {
      "title": "makan",
      "description": "makan di rumah",
      "isDone": false
    },
    {
      "title": "olahraga",
      "description": "jangan lupa olahraga",
      "isDone": false
    },
    {
      "title": "mindfulness",
      "description": "you have to mindfull",
      "isDone": false
    }
  ]
}

into GetTaskDTO object like bellow

GetTaskDTO.fromJson(jsonDecode(utf8.decode(response.bodyBytes)

now lets take a look at the GetTaskDTO

@unfreezed //--> this DTO are muttable
class GetTaskDTO with _$GetTaskDTO {
  factory GetTaskDTO({
    required final List<TaskModel> tasks,
  }) = _GetTaskDTO;

  factory GetTaskDTO.fromJson(Map<String, dynamic> json) =>
      _$GetTaskDTOFromJson(json);
}

this GetTaskDTO acting as our (Data Transfer Object) to wrap all the response from the API. and within this DTO there are list of TaskModel and will convert all the tasks object from json response into List of TaskModel..
now lets take a look at the TaskModel

@freezed //--> This object immutable
class TaskModel with _$TaskModel {
  factory TaskModel({
    required final String title,
    required final String description,
    //to set defaultValue using freezed
    @Default(false) bool isDone, 
  }) = _TaskModel;

  factory TaskModel.fromJson(Map<String, dynamic> json) =>
      _$TaskModelFromJson(json);
}

one thing about freezed, YOU HAVE TO MAKE SURE ALL YOUR FIELD NAMING AND CASE ARE FOLLOWING THE JSON RESPONSE FROM THE API

and now you have it. how your viewModel, can access the model through the API.. and convert all the Json Response from API directly into model.

References
http_package
Freezed_package

Next :
How To Use Flutter with Freeze
How To Use Flutter with Injectable

MVVM With Flutter (Part1){MVVM, Provider, Injectable, Freezed}

njoee — Thu, 11 Aug 2022 08:48:00 +0000

Hai!,

Here i'd like to record my code base line for flutter using MVVM pattern,

The Idea and the pattern

so the idea is i'd like to bind view and viewmodel one on one and making the viewmodel as our boiler plate to orchestrate all the logic related to its view like bellow.

i'm using these dependencies to run

Injectable --> Dependencies Injection
Freeze --> Model Mapper
Provider --> State Management

The Goal, What the apps will looks like

as a sample i create todolist app, like this

Now The Dev, lets deep into the code

now, in order to create the apps as above, we need 3 things.

1 Screen BIND to 1 View Model,
1 Repositories Available for any view model

1. Here is the MainScreen..

class MainScreen extends BaseView<MainScreenViewModel> {
  @override
  Widget build(
      BuildContext context, MainScreenViewModel viewModel, Widget? child) {
    return Scaffold(
      floatingActionButton: FloatingActionButton(
        onPressed: () {
          showModalBottomSheet(
              context: context,
              isScrollControlled: true,
              builder: (context) => SingleChildScrollView(
                    child: Container(
                        padding: EdgeInsets.only(
                            bottom: MediaQuery.of(context).viewInsets.bottom),
                        child: AddTaskScreen(onAddTaskClicked: viewModel.onAddTaskClicked,)),
                  ));
        },
        child: Icon(Icons.add),
      ),
      body: SafeArea(
        child: Container(
          color: Colors.lightBlue,
          child: Column(
            crossAxisAlignment: CrossAxisAlignment.start,
            children: [
              Container(
                padding: EdgeInsets.symmetric(horizontal: 30),
                margin: EdgeInsets.only(top: 50, left: 0),
                child: Column(
                  crossAxisAlignment: CrossAxisAlignment.start,
                  children: <Widget>[
                    Container(
                      child: Container(
                        child: CircleAvatar(
                          child: Icon(
                            Icons.list_rounded,
                            color: Colors.lightBlue,
                            size: 75,
                          ),
                          radius: 50,
                          backgroundColor: Colors.white,
                        ),
                      ),
                    ),
                    Container(
                      child: Text(
                        "What To Do!",
                        style: TextStyle(
                            fontSize: 30, fontWeight: FontWeight.w300),
                      ),
                    ),
                  ],
                ),
              ),
              Expanded(
                child: Container(
                  padding: EdgeInsets.symmetric(horizontal: 20),
                  decoration: BoxDecoration(
                      color: Colors.white,
                      borderRadius: BorderRadius.only(
                          topLeft: Radius.circular(30),
                          topRight: Radius.circular(30))),
                  margin: EdgeInsets.only(top: 25),
                  child: ListView.builder(
                    itemCount: viewModel.taskDataCount,
                    itemBuilder: (context, index) {
                      return ListViewTaskItem(data: viewModel.taskData[index]);
                  },),
                ),
              )
            ],
          ),
        ),
      ),
    );
  }
}

as you can see

Widget build(BuildContext context, MainScreenViewModel viewModel, Widget? child)

now having access to the viewModel, meaning you can access all the state within that viewModel.

and now here is the MainScreenViewModel

2. Here is the MainScreenViewModel..

@injectable
class MainScreenViewModel extends BaseViewModel {
  List<TaskModel>? _tasksData;

  final ITaskRepository _taskRepository = getIt<TaskRepositoryImpl>();

  List<TaskModel> get taskData => _tasksData ?? [];  
  int get taskDataCount => _tasksData?.length ?? 0;

  @override
  void init() async{
    _tasksData = await _taskRepository.getAllTask();
    notifyListeners();
  }

  Future<void> onAddTaskClicked(String textValue) async {
    final data = TaskModel(description: textValue,title: textValue, isDone: false);
    _tasksData?.add(data);
    notifyListeners();
  }
}

on that code above everytime whenever the init are invoke the viewModel will fetch the taskData from repositories _taskRepository.getAllTask();

3. and here is the task repositories looks like..

@singleton 
class TaskRepositoryImpl implements ITaskRepository{
  final String baseUrl = "run.mocky.io";

  @override
  Future<List<TaskModel>?> getAllTask() async{
    var url = Uri.https(baseUrl, "/v3/6bb86bda-08f1-4d7d-99c6-a975bc1201e0");
    final response = await networking.get(url);
    final responseBody = GetTaskDTO.fromJson(jsonDecode(utf8.decode(response.bodyBytes)) as Map<String,dynamic>);
    return responseBody.tasks;
  }
}

the repositories will responsible to makesure the data availability of task. and whenever the getAllTask() are invoked, repositories will fetch the data from the backendServies...

so now we have this flow :

...

When Is The ViewModel Are Injected?

ok up until here.. it was easy to understand right?. now we are moving to when exactly the viewModel are injected into view? how to make sure the viewModel are available when its needed.

First Lets take a look at the `MainScreenViewModel`

pay attention to the declaration.

@injectable
class MainScreenViewModel extends BaseViewModel

we put @injectable to the MainScreenViewModel telling our Dependencies Injection DI to make sure to create the MainScreenViewModel whenever it was fetch by getIt..
for example like

final viewModel = getIt<MainScreenViewModel>();

now getIt will create the object MainScreenViewModel and provide it to viewModel.

Ok, then where is the real one?

Back to our code structure, so where exactly the viewModel being injected to view? now you can open the BaseView class as bellow :

final RouteObserver<ModalRoute<void>> routeObserver =
    RouteObserver<ModalRoute<void>>();

abstract class BaseView<T extends BaseViewModel> extends StatefulWidget {
  BaseView({Key? key}) : super(key: key);

  Widget build(BuildContext context, T viewModel, Widget? child);

  @override
  State<BaseView> createState() => BaseViewState<T>();
}

class BaseViewState<T extends BaseViewModel> extends State<BaseView<T>>
    with RouteAware {
  T? viewModel = getIt<T>();

  @mustCallSuper
  @override
  void initState() {
    super.initState();
    viewModel?.init();
  }

  @mustCallSuper
  @override
  void didChangeDependencies() {
    super.didChangeDependencies();

    // subscribe for the change of route
    routeObserver.subscribe(this, ModalRoute.of(context) as PageRoute);
  }

  /// Called when the top route has been popped off, and the current route
  /// shows up.
  @mustCallSuper
  @override
  void didPopNext() {

    viewModel?.routingDidPopNext();
  }

  /// Called when the current route has been pushed.
  @mustCallSuper
  @override
  void didPush() {

    viewModel?.routingDidPush();
  }

  /// Called when the current route has been popped off.
  @mustCallSuper
  @override
  void didPop() {

    viewModel?.routingDidPop();
  }

  /// Called when a new route has been pushed, and the current route is no
  /// longer visible.
  @mustCallSuper
  @override
  void didPushNext() {

    viewModel?.routingDidPushNext();
  }

  @mustCallSuper
  @override
  void dispose() {
    routeObserver.unsubscribe(this);

    viewModel?.dispose();
    viewModel = null;
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider.value(
      value: viewModel,
      child: Consumer<T>(builder: widget.build),
    );
  }
}

now pay attention to the state implementation of BaseViewState, see this code

T? viewModel = getIt<T>();

this section is when the viewModel are injected to the view. so whenever you create a Screen extending to BaseView and you pump the ViewModel, then the ViewModel will become available for that view.

now, what kind of view model can be injected to view.

see this code :

class BaseView<T extends BaseViewModel>

this code saying that the Type of view model can be injected to view is only a view model that extend to BaseViewModel

here is the BaseViewModel looks like.

abstract class BaseViewModel extends ChangeNotifier{
  BaseViewModel();

  /// This method is executed exactly once for each State object Flutter's
  ///  framework creates.
  void init() {}

  ///  This method is executed whenever the Widget's Stateful State gets
  /// disposed. It might happen a few times, always matching the amount 
  /// of times `init` is called.
  void dispose();

  /// Called when the top route has been popped off, and the current route
  /// shows up.
  void routingDidPopNext() {}

  /// Called when the current route has been pushed.
  void routingDidPush() {}

  /// Called when the current route has been popped off.
  void routingDidPop() {}

  /// Called when a new route has been pushed, and the current route is no
  /// longer visible.
  void routingDidPushNext() {}
}

Pay attention to here

abstract class BaseViewModel extends ChangeNotifier

this saying that all the viewModel we create that extending BaseViewModel is a ChangeNotifier type. this make our View Model State able to be subscribed by other object, and any changes on our viewModel we can notify those changes to the viewModel subscriber.

So Where the provider scope are declared?

now get back to the BaseView class, and you'll find this section code.

@override
  Widget build(BuildContext context) {
    return ChangeNotifierProvider.value(
      value: viewModel,
      child: Consumer<T>(builder: widget.build),
    );
  }

whenever the view Extend to BaseView build the widget, the BaseView will first declare the provider first, so all the widget here..
child: Consumer<T>(builder: widget.build) will have access to the viewModel state.

Where Are We Now? how about the repositories?

remember this ?

nah, up until here.. now we have this diagram.

so now how about the repositories?

remember we would like to make the repositories as a singleton object, so whoever use the repositories, the object will remain single in our thread but available to many view models like this.

by the diagram above, it saying.. no matter how many screen are open with its own viewModel. and all those view model are using the Repositories(A) or Repositories(B) the Repositories itself remain only one object in our memory. thats why we have to told to our DI to make our repository as @singleton...Here is the link explain more about the singleton

##Back to our app,
as you can see previously on the TaskRepositoryImpl
the declaration is like this

@singleton 
class TaskRepositoryImpl implements ITaskRepository

this should make our TaskRepository as a singleton object, so in our case.. whenever MainScreenViewModel require TaskRepositoryImpl as the code bellow :

final ITaskRepository _taskRepository = getIt<TaskRepositoryImpl>();

our DI will return the existing object of the repository in the memory..

#Fine, Now how to run the code?
well, talking about the Injectable Package all those repositories and viewmodel with
@injectable and @singleton will actually generating implementation file before the flutter itself compiling.. so before we run our application, whenever you create new class with injectable annotation. you have to run this command
fvm flutter pub run build_runner build --delete-conflicting-outputs
you have to ask the build runner to create the implementation file.

Well, What is next?

oke, we haven't talk about how the repositories can communicate with the rest API?..
lets discuss about it MVVM With Flutter (Part2)

until then, you can enjoy the code Here..

Thanks Guys, hope this help for you to start the project with flutter.
P.S This are my codebaseline whenever i start a new project feel free to clone it.

Next :
MVVM With Flutter part 2
How To Use Flutter with Freeze
How To Use Flutter with Injectable