What am I building? ❓

I had the idea that I wanted to build a Crossfit training app for gyms and athletes. I named it Dreamwod and just launched it on App Store and Google Play. The things that I have been building are two apps, one for iOS and one for Android, a backend API, and a company web page.

This article will talk about the tech stack, ways of working, what I have learned and what mistakes I made.

Deciding on the Tech Stack 🤔

The requirements I had on the tech stack were the following.

Backend and operations

1. Quick development and iteration time.
2. Easy to run locally.
3. Easy to scale the backend / be able to handle high load.
4. Easy to deploy.
5. Keep it as simple as possible.

App development

1. Easy to learn (I didn’t have any experience of iOS app development).

The stack

Backend - Golang 💻

The language of choice for the backend was golang. I wanted something that was easy to learn, quick to compile, had a good performance, and had a low memory and CPU footprint in production.

Apps — Flutter ☎️

I didn’t have a lot of experience with either iOS or Android and I wanted apps for both platforms so the decision was pretty easy, try Flutter and see if it works. Very happy with that decision!

Database — PostgreSQL 🏬

I had several options available when picking a database. The assumptions I based the decision on were,

• Data will be shared between users, i.e. the data in the app is not only viewed and edited by the user uploading it.
• I would have some joins and interconnected tables.
• I assumed that I wanted support for full-text search and didn’t want to spend the time and energy on ElasticSearch or something similar.

The decision was to go with Postgres. It got full-text search support out of the box with the pg_trgm extension. It also has good support for PostGIS with the postgis extension so it’s easy to calculate coordinates and distance from the user to for example a gym.

Cloud — GCP ☁️

I looked at two options for hosting, Google Cloud Platform (GCP)and AWS. I picked GCP because I could then run the backend API on Cloud Run and only pay for the processing time, which basically has been zero during development and beta.

Some other useful tools that I’ve been using,

Cloud Build for building containers. Since I’m the only developer and not building that many containers then I’m easily within their free their of 120 minutes/day.

Cloud Storage is used for content uploaded by users.

Pub/sub is used for async processing, see the article for how I use an approach where I can develop locally as well as deploy it easily to GCP.

The monthly bill right now is around $30, of that is the two largest services load balancer for the CDN $18 and the Postgres $10. This bill will increase when I get more users and need to use larger database instances but the cost should still be fairly low for quite some users.

Emails — Mailgun 📫

There are a lot of options out there, just picked Mailgun since I have used them in the past.

Payments — Stripe 💰

I’m adding support for subscriptions in the app and using Stripe was a good decision since they have a subscription portal for users where they can cancel and change subscriptions.

Company Web Page — Webflow 🕸

I picked webflow as the framework/tool for the company web page. I was looking for something simple that I could set up and then forget. Web page available at www.dreamwod.app.

Way of working

No tests 🛑

Not common to see this statement and maybe it’s something that will turn out to be a mistake later on but here are the top reasons why I haven’t added more than 5-10 tests in the backend project.

• As the solo developer (Backend, Frontend, QA) then I will test the backend code when I implement the frontend.
• Adding tests takes a lot of time. When building this app it has been a lot of experimenting and trying out ideas and adding tests for something I wouldn’t use would slow down the development speed.
• The things that I have tests for are mostly regular expression-related parsing, so it was quicker to write tests compared to testing the API directly.

Monolith instead of microservices 🐻

Always a bit controversial to go with one service instead of a microservice strategy but the reason why I only have one backend API/service is that.

• I don’t want to spend time defining contracts/API and solving hosting-related problems that come with a multi-service approach.
• It’s hard to know where to split a single service into different ones when starting a new project. My bet is that it’s easier to do this later if/when it’s needed.
• I don’t have a lot of load on the system so I don’t have any issues with performance bottlenecks or special flows in the backend that needs to be optimized.

With this said, it’s of course still good to divide the code into different areas/domains and not have “spaghetti code” in the codebase.

What have I learned? 🎒

• “The last 20% takes 80% of the time”, is a famous quote but it’s been true for me. The last things have taken a lot longer time than anticipated.
• Working on my own means that I don’t have any strict deadlines but it can be hard to focus. I have learned that for me it works best if I have as many routines as possible when it comes to coding, training, etc as you have in a normal 9–5 job. A typical day would be one coding session before lunch, a longer lunch break with a gym session, and then a coding session in the afternoon.

What would I do differently in the Tech Stack?

I am overall very happy with the tech stack and it isn’t a lot of things that I would have changed. But some things that I would have done differently are:

• I would have investigated if GraphQL API would have been a better option instead of a REST API.
• I’m a bit concerned that it can be tricky to scale (let’s see if it ever will be needed) the solution globally. The database and services are hosted in Belgium's data center right now and there would be a high latency if someone would use it from for example US or Brazil.

What would I do differently from a product point-of-view?

Sometimes it would have been better to take a “quick and easy” solution instead of a “correct one”.

• An example was that Cloud Run was kind of new when I started and they didn’t support some things like retrieving secrets from the GCP Secrets Manager. I spend some time on implementing something around that and it would have been better if I just did some quick and easy hack and then waited on proper support from Google Cloud.

Conclusions

It’s always easy to look back at the things and to think about those things that didn’t go the way you planned, but it’s equally important to think about the things that actually worked out really well, that’s one of the reasons why I wrote this short article — to reflect on the things that worked good 😎.

If you are thinking about starting a company as a solo developer, stop thinking and do it! It’s a lot of fun! 🚀

How I built my tech startup as a solo developer was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

Dreamwod is a Crossfit app where a lot of athletes are using the Concept2 machines for biking, rowing, and skiing. These machines have a memory where athletes can get statistics and split times over a workout. We have developed a feature where the athletes can take a picture of the screen (see below) and the data/text is recognized and imported directly into Dreamwod.

Below is an example screen of a 6x2000m interval rowing session with 4 minutes of rest between each interval. /500m is the average time per 500m and s/m means strokes per minute.

The source code with examples and descriptions are available here https://github.com/dreamwod-app/mlkit-vs-cloud-vision.

The two alternatives, MLKit vs Google Cloud Vision

We have looked at two different alternatives when performing the OCR. We looked at Google MLKit on the client-side and Cloud Vision API on the backend side, both alternatives have their drawbacks and advantages.

Flutter MLKit

The first alternative is to use Flutter MLKit and do the OCR scanning directly in the app and then send the extracted text to the backend. The advantage of this is obvious that the load is on the app side and we don’t have to do anything on the backend “more” than understanding the scanned content. The main drawback, which we will see later, is that the quality of the OCR is poor.

Pros
+ Client/app side processing
+ Free (no additional cost)
+ Quick (~1 second to get the result)

Cons
- Bad quality on the OCR
- Does not work on all devices

Google Cloud Vision API

The second alternative is to use Cloud Vision API, upload the image and do the processing on the backend side, for example with Cloud Run or a Cloud Function.

Pros
+ Good performance
+ Works on older devices

Cons
- Increased backend load
- Additional cost (*)

(*) The first 1000 calls every month to the Vision API are free and then the price is $1.5 per 1000 requests.

Implementations

Cloud Vision API

Full implementation of the example program is available at https://github.com/dreamwod-app/mlkit-vs-cloud-vision. Check out the code, compile and run it with one of the example images below.

$ git clone git@github.com:dreamwod-app/mlkit-vs-cloud-vision.git
$ go build
$ ./mlkit-vs-cloud-vision vision -image images/example_2.jpg -out output/example_vision_2.jpg

The program will read the example image and call the Cloud Vision API. The program will then use the response and draw rectangles around the red rectangles where the text was found.

The examples in the Github repository contain four different images with different quality and resolutions. It’s possible to use any image, just replace the -image and the -out arguments.

$ ./mlkit-vs-cloud-vision vision -image any-image.jpg -out out.jpg

MLKit with Flutter

There are some different flutter packages out there for ML but the most up-to-date is google_ml_kit which is using the models from the Google MLKit at https://developers.google.com/ml-kit.

The example below will output coordinates of the detected areas and a file with these can be provided to the golang library and to draw a similar image as for Cloud Vision.

$ ./mlkit-vs-cloud-vision draw -image images/example_1.jpg -out output/example_mlkit_1.jpg -coords coords/coords1.txt

Results

It looks like the examples above are pretty similar but it turns out that there is a huge difference between the Cloud Vision API and MLKit. One of the four images couldn’t be used at all with MLKit and the quality of the extracted text is poor.

• One of the four images couldn’t be used with MLKit, no text was detected.
• MLKit failed to detect a lot of numbers. It especially has trouble seeing the difference between “3” and “B”, 3.41.8 is seen as B.41.8.
• MLKit see number very differently, 2:03.5 are for example returned as 2:03.5, 2:035, 2:03,5, 203.5 etc.
• The only real issue for Cloud Vision was that it couldn’t detect “s” and “/” correctly when the s was superscripted in “s/m”.

The table below is a summary of the result, Cloud Vision detects almost everything, and MLKit has quite some texts that aren’t recognized correctly.

Complete results are available at https://github.com/dreamwod-app/mlkit-vs-cloud-vision#results.

Conclusion

Doing machine learning on the client/app side is cool but the quality of the recognized texts is in our use case not good enough. There could be other scenarios where it is working better and with higher quality. We are because of that using Cloud Vision API for the upcoming feature of importing the Concept 2 results directly into Dreamwod.

Hope it helps when choosing between Cloud Vision and MLKit for text recognition! 🚀

Cloud Vision vs Flutter MLKit for OCR detection of Concept2 machine was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Dreamwod app supports three ways of signing up, Email&Password, with Apple Id, or through Google. This article will describe the setup for AppleId and Google both in the flutter app as well in the golang backend.

Our requirements

• Apple Id and Google should work on both iOS and Android (since users can have with multiple devices)
• Use available flutter packages if they are available
• No hard dependency on Firebase (i.e. we don’t store users in their database)
• Backend in Golang

Sign in with Apple Id

Outline of the flow (on iOS):

1. The user clicks SignIn with Apple.
2. User confirms and an authentication token is received from Apple.
3. The token is sent from the app to the backend.
4. The backend validates the token to make sure it’s valid.
5. The user is created or logged in.
6. JWT access and refresh tokens are returned to the user.

The package sign_in_with_apple is the package that we are using for authentication in the app.

The webAuthenticationOptions are needed if the user is signing in from an Android device, more about that later.

The sign-in request that is sent from the app to the backend looks like below. First and last name needs to be included since it’s not part of the authorization code. A flag if the request is from Android or not is also included since those need to be validated by a different ClientId in the backend.

final request = AppleSignInRequest(
  firstName: credentials.givenName,
  lastName: credentials.familyName,
  authorizationCode: credentials.authorizationCode,
  isAndroid: Platform.isAndroid,
);

The backend needs to validate the authorization code to make sure that it is valid. The go package go-signin-with-apple is used for validating and tokens. The information that is needed for validation is teamId, clientId, keyId, and the private key. We also use a different clientId for android, see below.

appleSignIn:
  teamId: <...>
  clientId: com.dreamwod.app
  androidClientId: com.dreamwod.app.login
  keyId: <...>
  privateKey: |
    -----BEGIN PRIVATE KEY-----
    ....
    -----END PRIVATE KEY-----

The authenticator that is validating the token is shown below, the validation returns the unique id and the email of the user.

The flow is pretty straightforward on iOS. It's a bit more complicated on Android devices since those are using a web-based flow.

Outline of the flow (on Android):

1. The user clicks SignIn with Apple.
2. A web view is opened and the user logs in with Apple credentials
3. The user is redirected back to the redirectURI in the webAuthenticationOptions.
4. Our server at redirectURI redirects the user back to the app with the payload from Apple
5. Same steps as in the iOS flow…

Redirect URI

In our case, we have the server running and endpoint at auth/callbacks/apple-sign-in and when we receive a POST request the below code is executed and there is a temporary redirect back to the app. The AndroidManifest.xml needs to be updated with the instructions at sign_in_with_apple for it to work.

data, err := ioutil.ReadAll(c.Request.Body)

if err != nil {
   _ = c.AbortWithError(http.StatusInternalServerError, err)
   return
}

c.Redirect(http.StatusTemporaryRedirect, "intent://callback?"+string(data)+"#Intent;package=com.dreamwod.app;scheme=signinwithapple;end")

Sign in with Google

Outline of the flow (both iOS and Android):

1. The user clicks SignIn with Google.
2. User confirms and an id token is received.
3. The token is sent from the app to the backend.
4. The backend validates the token to make sure it’s valid.
5. The user is created or logged in.
6. JWT access and refresh tokens are returned to the user.

The package google_sign_in is the package that we are using for the sign-in.

The id token is returned from the sign-in operation and sent to the backend. We don’t get the first and the last name of the user in the same way as through Apple.

final request = GoogleSignInRequest(
  idToken: idToken
);

The backend validates and the id token and retrieves email, first and last name. More information can be requested by extending the scope request. The audience is validated, we have two audiences, one for iOS and one for Android so the audience parameter to idToken.Validate(context, token, audience) isn’t used.

The Google flow is a bit easier to set up since the same flow is used both for iOS and Android.

Conclusions & Tips

• Be sure to allow CORS for https://appleid.apple.com in your backend.
• See Flutter bloc authentication flow for a walkthrough of an authentication bloc flow in the app.
• Decide on if you should threaten Google users as separate users from Email and password users or if they can log in through their Google account and/or password.
• Make sure to test the flows on both iOS and Android devices and make sure to test different and weird scenarios.
• Make sure to store the unique apple id of the users in your backend and that as an identifier for the user
• Consider using different login paths in your backend, like POST /auth/apple, POST /auth/google, POST /auth/email but return the same response back from all of them so the code in the app can share the same logic. In our case, we return email, JWT access&refresh codes, and the authentication method.
• Consider storing the last used authentication method in the app. In our app, we use it when the user logs out since we only want to pre-fill the email field only if the user did authenticate with email and password.

That’s it! 🚀

Sign in with Apple and Google in Flutter App + Golang backend was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

• The Dreamwod app is talking with a backend Rest API.
• The API is secured with JWT Tokens. One refresh token, long TTL, is exchanged to access tokens with short TTL.

Why Dio?

The primary reasons why we migrated from the standard http package to Dio are:

• It’s easier to add interceptors when handling requests and errors (i.e when refreshing JWT tokens).
• Less boilerplate code.
• Cleaner code.

Architecture

Our flutter app is structured in the following way:

• lib/models: RPC and models with the standard JSON-serializable annotations.

• lib/services: We use one service for every part of the API, for example, user_service.dart, about_service.dart, notification_service.dart etc.

• lib/api: Services are using an API class for communicating with the backend. We have two Dio clients in the class, one is used for all requests except when the token is refreshed, then we use a dedicated Dio client.

Handling refresh of tokens

We have a 15 minutes time-to-live on our access tokens and we refresh them if they have less than 1 minute remaining, see above. We use requestlock.lock() and requestlock.unlock() so we don’t have concurrent refresh requests.

The package jwt_decode can be used to parse the expiration time from a JWTtoken.

Error handling

Using exceptions makes it easier to catch and handle different kinds of errors. Our error interceptor below which handles different HTTP status codes and converts them to appropriate exceptions.

Example of a “catch all” try-catch block.

try {
  var user = await UserService().getUser();

  yield UserLoaded(user: user);
} on Exception catch (e) {
  yield LoadUserFailed(error: e.toString());
}

Example of a when different exceptions are caught.

try {
    final response =
        await UserService().login(event.email, event.password);

    //... other authentication code

    yield SignInSuccess();
  } on UnauthorizedException {
    yield SignInFailure('Invalid email or password. Please try again.');
  } catch (error) {
    yield SignInFailure(error.toString());
  }
}

Summary

That's it! Hope it helps!

Flutter + Dio Framework + Best practices was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article will show how golang can be used for digital signal processing (DSP) on a raw PPG or ECG heartbeat signal. We will use the fast Fourier transform (FFT) to look at the frequency spectrum, clean up noise from the signal using low and highpass filter, and finish by implementing r-peak detection on the signal to calculate the r-interval and the average heartbeat.

To outline the different steps,

1. Read and visualize the signal
2. Frequency analysis with FFT and signal filtering
3. R-peak detection and heartbeat calculation
4. Conclusions

Source code and packages used

https://github.com/eripe970/go-dsp-utils is the go package used in this article, it’s a wrapper around some of the most popular packages for DSP in golang. The example used in this article is also available in that repository.

To run the example just do

$ git clone github.com/eripe970/go-dsp-utils
$ cd go-dsp-utils
$ go run examples/advanced/main.go

And then go to localhost:4000

1. Read and visualize the signal

The chart below shows the signal that we will use as an example in this article. Each peak in the signal is an r-peak and our goal is to calculate the time between the peaks and by that calculate the heart rate.

Importing a signal from a file can be done with the utility function ReadSignalFile.

signal, _ := dsp.ReadSignalFile("example_signal_100_hz.txt", 100)

We can then also look at a 10 seconds sample of the signal with the code.

signal10s := signal.Sample(10 * time.Second)

2. Frequency analysis with FFT

We need to normalize the amplitude of the signal between -1 and 1 to more easily look at the frequency spectrum. An algorithm for that is implemented so we can easily get a normalized signal with the code.

normalized, err := signal.Normalize()

Calculating the Fast Fourier Transform (FFT) on the signal means that we can look at the signal in the frequency domain instead of the time domain. The code is not that complicated, the FFT is first calculated from the signal. Then we compute the two-sided spectrum spectrum2and after that, we compute the single-sided spectrum spectrum1 based on spectrum2 and the length of the signal.

If we now plot the frequency spectrum of the signal we see something like below.

We see that the peak around 0.92Hz (55 bpm). The next step that we want to do is to run the signal through a bandpass filter to remove some of the noise from the low and high frequencies that we don’t care about. The code to do that is,

filtered, err := signal.BandPassFilter(0.5, 1.2)

We assume that we in our example only care about heart rates between 30 BMP (0.5Hz)and 70 bpm (1.2Hz).

If we then look at the final signal it looks like below.

3. R-peak detection

Detecting the heart-beats is as simple as doing a peak detection on the signal. In our library, it’s done with the code.

rPeaks := dsp.GetRPeaks(signal) 

Not easy to see in the graph but each red line is where an r-peak is detected. Displaying the r-interval time and the heartbeat gives us the following charts.

4. Conclusions

That’s all for the first part! The source code is available at https://github.com/eripe970/go-dsp-utils.

The next article will continue on this one and we will use TimescaleDB and Grafana to calculate and plot the heartbeats in real-time.

Digital Signal Processing with golang was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the second post in a series on how the Dreamwod app is built. The Dreamwod app is an iOS and Android app for CrossFit athletes where they can track their progress and for CrossFit gyms that want their athletes to engage in their community. We have previously described the components and package used to build a “details page” in the app. This post will take a step back and instead look at the onboarding flow and how the bloc pattern can be used to structure the logic around onboarding and authentication.

The series contains (at least) the following posts.

1. Components used for building the details page.
2. Flutter bloc authentication flow (this post).
3. Push notifications setup (available later).
4. Components used for building the profile page (available later).
5. Integrating Stripe for payments (available later).
6. Build and publish with Fastlane (available later).

Prerequisites

Bloc pattern

Flutter_bloc is a package that can be used to separate the presentation logic from the business logic. It is typically achieved by sending events into a bloc and have the bloc update the app state. A lot of good examples are available here.

Secure storage

Our app uses JWT tokens for authentication. The JWT is sensitive information and should be stored in a secure way. We are using the flutter_secure_storage package for this and have wrapped the read and write logic into a repository which the app can use.

Onboarding and authentication flow

The above state diagram describes an overview of how the authentication flow works. Our app is wrapped in an AuthenticationBloc and the AppStarted event is fired directly at the start of the app.

The logic in the Authentication bloc is pretty simple, events are handled and the state is changed.

Some things are worth pointing out.

1. This bloc is also a good place to set up other things like error logging towards Sentry, Firebase Analytics, register Firebase push notifications, etc.
2. The start state is AuthenticationUninitialized. We use this special state so that a loading spinner can be displayed when the AppStarted event is processed.
3. We check if the app is started for the first time after install/re-install. One problem with using the flutter_secure_storage package is that information is stored in the iOS keychain. Information in the key chain will be available even after the app is re-installed. That is not something that we want so we have a check that will clear everything after an install/re-install. The information if it’s the first run is stored in the SharedPreferences. SharedPreferences are deleted when the app is uninstalled.
4. This bloc doesn’t handle the logic for login. That is handled by a SignInBloc which emits a LoginEvent with the JWT token and the email of the user to the AuthenticationBloc. See the example below. This separates the logic in a good way between different blocs and views.

Updating the UI on different states

Different states map to different screens. The AuthenticationAuthenticated state is the only state that will display the app for authenticated users.

Testing the flows

Using a global observer on the blocs is a must to be able to follow between events and state transitions. The observer below will log all events and states and make it easier to follow the transitions. Can be added with Bloc.observer = LoggingBlocDelegate();

Example 1. Starting the app without a JWT Token.

Transition { currentState: Instance of ‘AuthenticationUninitialized’, event: Instance of ‘AppStarted’, nextState: Instance of ‘AuthenticationUnauthenticated’}

Straight forward, the event AppStarted is changing the state to AuthenticationUnauthenticated since the user isn’t authenticated.

Example 2. Log in with email/password

Transition { currentState: Instance of ‘SignInInitial’, event: Instance of ‘SignInButtonPressed’, nextState: Instance of ‘SignInLoading’ } (SignInBloc)

Transition { currentState: Instance of ‘SignInLoading’, event: Instance of ‘SignInButtonPressed’, nextState: Instance of ‘SignInSuccess’ } (SignInBloc)

Transition { currentState: Instance of ‘AuthenticationLoading’, event: Instance of ‘LoggedIn’, nextState: Instance of ‘AuthenticationAuthenticated’ } (AuthenticationBloc)

A bit more complicated. The first state transition happens when the user taps the SignIn button. The second one is the transition when the password is verified in the backend. The third transition is when the AuthenticationBloc processed the event that the user is logged in and changes the state.

Example 3. Logout

Transition { currentState: Instance of ‘AuthenticationAuthenticated’, event: Instance of ‘LoggedOut’, nextState: Instance of ‘AuthenticationLoggingOut’ }

Transition { currentState: Instance of ‘AuthenticationLoggingOut’, event: Instance of ‘LoggedOut’, nextState: Instance of ‘AuthenticationUnauthenticated’ }

State changes from AuthenticationAuthenticated >AuthenticationLoggingOut > AuthenticationUnauthenticated. It can take a second or two to log out so the state AuthenticationLoggingOut is used for displaying a loading spinner.

Conclusions

Using the bloc framework can be a good approach when designing a flow with different states, for example an authentication and onboarding flow. Some key takeaways.

• Don’t try to add too much logic into the same bloc, better to separate into several blocs.
• Wrap the app in the main bloc responsible for authentication and use that to change between authenticated and unauthenticated states.
• Use intermediate loading states for operations that take longer time.
• Events can be added directly in the initialization of blocs with the ..add(MyEvent); syntax.
• Don't forget to test edge cases and error scenarios. The authentication flow must be rock solid!

Good luck! 💪

Flutter bloc authentication flow was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Components, best practices, and tools used to build a large Flutter app.

This is the first post in a series on how the Dreamwod app is built. The Dreamwod app is an iOS and Android app for CrossFit athletes where they can track their progress and for CrossFit gyms that want their athletes to engage in their community. We have previously described how we have created some of the backend services (Golang + CloudRun at Google Cloud) and now it’s time to discuss the app.

The series contains (at least) the following posts.

1. Components used for building the details page (this post).
2. Flutter authentication flow with bloc pattern.
3. Flutter + dio framework + best practices
4. Components used for building the profile page (available later).
5. Integrating Stripe for payments (available later).
6. Build and publish with Fastlane (available later).

Scoreboard screen

In the Dreamwod app, athletes register their scores in different daily workouts. The scoreboard result screen displays the scores and athletes can navigate to a certain score to check out the details. This post focus on the details page and the different components used to build it.

The scoreboard results screen is pretty simple with different list tiles group by different categories. The focus of this post is the details page for the scores.

Details page

The details page is the page where a score and comment about a workout is displayed. The functionality on this page is.

• Pull down to refresh the page.
• Like/unlike the workout/score.
• Add a comment (text and or emoji).
• Add a gif comment (Giphy integration).
• List comments and scroll to the latest one added.
• Display nicely formatted posted date on comments.
• Facebook style reactions (with 😂, 👍 or other emojis) on the comments.
• Add reactions and display a chip/badge to show the number of reactions

Additional functionality not seen on the image below is also

• Loading overlay
• Haptic feedback

Loading overlay

The component loading_overlay is used to display a loading overlay when data from the backend is loaded. isLoading is initialized to true and then unset when the data from the backend is available.

Scaffold(
    backgroundColor: Theme.of(context).scaffoldBackgroundColor,
    appBar: AppBar(
      title: Text('Workout result'),
    ),
    body: LoadingOverlay(
        isLoading: isLoading,
        child: ... )
);

Pull to refresh

The package pull_to_refresh is used for refreshing when the user pulls down.

SmartRefresher(
    enablePullDown: true,
    header: ClassicHeader(),
    onRefresh: onRefresh,
    controller: refreshController,
    child: ListView(controller: scrollController, children:
        getBody())));

Like button with animation

The package like_button is used for creating the animations that are displayed when a user likes a workout. The logic is pretty straight forward and the like and count builders can be used to display different messages depending on how many likes there are.

LikeButton(
  onTap: (onLikeButtonTapped),
  size: 26,
  isLiked: isLiked,
  likeCount: numberOfLikes,
  likeCountAnimationType: LikeCountAnimationType.all,
  likeBuilder: (bool isLiked) {
    return Icon(
      Icons.favorite,
      color: isLiked ? Colors.pinkAccent : Colors.grey,
      size: 26,
    );
  },
  countBuilder: (int count, bool isLiked, String text) {
    if (count == 0) {
      return Text('Tap to like!');
    } else if (count == 1 && isLiked) {
      return Text('You like this!');
    }

    return Text('${count} ${(count == 1 ? 'athlete' : 'athletes')} likes this'
    );
  },
),

Emoji sizing

The default size of emojis in flutter text is a bit too small for us. We want to scale them up so they stand out more around the text.

This can be achieved by a component that scales up the text.

class EmojiText extends StatelessWidget {
  final String text;
  final TextStyle style;
  final double emojiFontMultiplier;

  const EmojiText({
    @required this.text,
    @required this.style,
    this.emojiFontMultiplier = 1.3,
  });

  // Regex to match emojis
  static final regex = RegExp(
      '((?:\u00a9|\u00ae|[\u2000-\u3300]|\ufe0f|[\ud83c-\ud83e][\udc00-\udfff]|\udb40[\udc61-\udc7f])+)');

  List<TextSpan> generateTextSpans(String text) {
    var spans = <TextSpan>[];
    final emojiStyle = style.copyWith(
      fontSize: (style.fontSize * emojiFontMultiplier),
      letterSpacing: 2,
    );

    text.splitMapJoin(
      regex,
      onMatch: (m) {
        spans.add(
          TextSpan(
            text: m.group(0),
            style: emojiStyle,
          ),
        );
        return '';
      },
      onNonMatch: (s) {
        spans.add(TextSpan(text: s));
        return '';
      },
    );
    return spans;
  }

  @override
  Widget build(BuildContext context) {
    return Container(
      child: RichText(
        text: TextSpan(children: generateTextSpans(text), style: style),
      ),
    );
  }
}

We also have a utility function that can be used to check if all characters in a string are emojis so that the text can be scaled even more.

class Utils {
  static final emailRegExp = RegExp(
      r'^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$');

  static final onlyEmojiRegExp = RegExp(
      '^(\u00a9|\u00ae|[\u2000-\u3300]|\ufe0f|[\ud83c-\ud83e][\udc00-\udfff]|\udb40[\udc61-\udc7f]|\s|\t|\n|\r)*\$');

  static bool isOnlyEmojis(String comment) {
    return onlyEmojiRegExp.hasMatch(comment);
  }
}

Used for example like below

EmojiText(
  text: comment,
  style: style,
  emojiFontMultiplier: Utils.isOnlyEmojis(comment) ? 3: 1.4,
);

Display time

The component used to format time nicely is called timeago. It is that component that will format dates like “a moment ago”, “24 hours ago” etc.

Facebook-style reaction button & badges

The package used to create the reaction buttons is the package flutter_reaction_button. A flutter chip could have been used to create the badge counting the reactions but it is often too large even if with padding set to zero. The badges package is the rescue!

Gif support through giphy

We are using the giphy_picker package when adding images. The only code needed is below. The package contains all the logic and the only thing needed is to pick the URL and store it in the backend.

GestureDetector(
    onTap: () async {
      final gif = await GiphyPicker.pickGif(
          context: context,
          apiKey: 'your-api-key');

      if (gif != null) {
        addGif(gif);
      }
    },
    child: Icon(Icons.gif_rounded));

void addGif(GiphyGif gif) {
  BlocProvider.of<ScoreBloc>(context).add(AddComment(
      url: gif.images.original.url));

  setState(() {
     // Todo: reset the focus in a better way
     FocusScope.of(context).requestFocus(FocusNode());
  });
}

Cupertino rounded corners

A great flutter package to make Cupertino rounded corners (also referred to as squircles) is the cupertino_rounded_corners. See the example in the emoji scaling section.

Cached network image

Users will look at the same comments multiple times so it makes sense to cache the gif animations. An excellent package for this is cached_network_image. It also supports a loading placeholder and an error widget.

CachedNetworkImage(
  imageUrl: url,
  placeholder: (context, url) => Padding(
    padding: const EdgeInsets.symmetric(
        vertical: 40, horizontal: 80),
    child: Container(
      child: CircularProgressIndicator(),
    ),
  ),
  errorWidget: (context, url, error) =>
      Icon(Icons.error),
);

Haptic feedback

Haptic feedback can be added when for example the like button is pressed.

Future<bool> onLikeButtonTapped(bool isLiked) async {
  // todo, code for handling the event

  await HapticFeedback.lightImpact();

  return !isLiked;
}

That's all for the first part!

Complete Flutter app walkthrough Part 1 was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

Cloud Run will throttle the CPU when there isn’t an active request processing. That means that it isn’t possible to spawn a new thread or goroutine to do background processing within a Cloud Run API. Background processing can for example be to send an email during registration or to send push notifications when a user likes a post, something that the user doesn’t have to wait for.

This article will describe a solution for asynchronous processing where an API running on Cloud Run will send events to Pub/Sub. These events will then be sent back to the API through a Pub/Sub push subscription.

1. An API request is sent to a Cloud Run service.
2. The API request is processed and events are sent to an event topic in Pub/Sub.
3. The API response is returned back the client and the CPU will be throttled.
4. Pub/Sub pushes an event back to the API Service for asynchronous processing.

In our example, we will have a golang REST API with two methods.

POST /change-name    // Used to change the name of a user
POST /events         // Used by Pub/Sub for processing events

Source code and example

The library used for signing and consuming events and an end-to-end example is available at https://github.com/eripe970/pubsub-signing.

Create events

Pub/Sub required that the Cloud Run allows all public traffic to be able to receive events. It supports authentication of requests and as an extra security measurement, we will sign each message to be sure that they are sent from the API. The GCP requirement that the API must be public means that we cannot have an internal API that handles the events.

The event-type is stored on the message as an attribute. Each message is signed with a secret and the signature is verified when the event is processed in the event handler in the API.

The contents of the event will look like below.

{
  "message": {
    "attributes": {
      "event-type": "user.name.changed",
      "signature": "cc6d0457d8b4ec0e994d793302cd6962a0d12101abbc79e561f532a826eca4ee"
    },
    "data": "eyJOYW1lIjoibmV3LW5hbWUifQ=="
  },
  "subscription": "api-events"
}

Event-type will be used for the deserialization of the event when it is processed in the api.

The signature is a hex-encoded signature that will be verified when the message is deserialized.

Data is base64 encoded payload (automatically encoded by GCP).

Subscription can be used to know which subscription the message originates from (automatically added by GCP).

Consume Events

The code below constructs the message and validates the signature. The event will also be deserialized depending on its type.

Developing locally

One option when developing locally is to use the Pub/Sub emulator from https://cloud.google.com/pubsub/docs/emulator. Another option is to have two implementations for publishing messages. One to use at GCP that publishes messages to Pub/Sub and one to use locally that makes a HTTP request directly back to the API.

Cloud Run vs Cloud Functions

Events can also be processed by a Cloud Function instead of an API on Cloud Run. Some pros with processing with Cloud Run instead of Cloud Function.

• Support languages/versions that Cloud Functions does not yet support (any docker image).
• Cloud Run can handle multiple types of events/messages in one deployment.
• May not be impacted by cold starts in the same way as Cloud Functions.

Summary

Using Cloud Run in combination with a push subscription on Pub/Sub is a good alternative to Cloud Functions for handling asynchronous processing of events. Try it out!

Asynchronous processing with Cloud Run and Pub/Sub was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

Kubernetes at Google Cloud (GKE) was used during the development and the testing of the Dreamwod app (https://www.dreamwod.app). GKE has been working good but it has also been the most expensive and complicated part of the hosting. We have because of that been migrated from GKE to Cloud Run. The primary reasons behind the migrations are.

1. Cost - Cloud Run is cheaper than GKE (for our workload).
2. Simplicity - Our API is pretty simple and we don’t need a lot of the extra features in Kubernetes.

Migrating secrets

When migrating to Cloud Run we decided to store our secrets in Google Cloud Secret Manager. There isn’t a native Cloud Run integration with Secret Manager so the recommended way forward is to load any secrets when the container is starting. We decided to store the whole .yml config file in one secret so we can start the container after only one request to Secret Manager.

Migrating Cloud SQL

We used cloud-sql-proxy as a sidecar when connecting to Cloud SQL from Kubernetes. The cloud-sql-proxy functionality is already built-in into Cloud Run so the only thing that needs to be done is to add the connection and to update the connection string. On Kubernetes we used the following configuration and the connection string postgresql://username:password@127.0.0.1?sslmode=disable.

On Cloud Run we used the following connection string postgresql://username:password@:5432/database-name?host=/cloudsql/<instance-connection-name>

Migrating asynchronous tasks

We had certain functionality when we for example did processing of images in the background using goroutines. That had to be changed since Cloud Run throttle the CPU if no requests are active.

The new approach is instead to send messages to Cloud Pub/Sub when we need to do background processing and then have a subscription that pushes messages back to the API. The below code publishes events of different types to Pub/Sub.

Migrating the build pipeline

We use Cloud Build for building and deploying containers. Deploying with Cloud Run is just adding one extra step to the build pipeline.

Migrating DNS

We added a subdomain mapping in Cloud Run, updated the DNS and the migration was finished.

Updating logging

We use gin-gonic as the web framework and Zap for logging.

1. Request logging was disabled in gin-gonic since Cloud Run is logging all requests.
2. Zap is updated with below to make Cloud Logging pick up the severity.

Conclusion

Performance

We don’t have a lot of load on the API but we haven’t been able to see any performance degradations after the move to Cloud Run.

Startup time

The startup time for processing a request when the instance is cold is impressive. For our API it’s between 1 and 2s. That includes starting the container, doing a database migration/update check and loading configuration from Secret Manager.

Cost

A typical month for us (everything hosted in Amsterdam datacenter) with Kubernetes was around $70/month.

1. Compute Engine $58 (84%)
2. Cloud SQL $11 (15%)
3. Others $1 (1%)

When running on Cloud Run we are currently in the free tier which means that the cost for Cloud Run is zero. The total cost is around $12/month.

1. Cloud SQL $11 (91%)
2. Others $2 (9%)

Migrating from GKE to Cloud Run was originally published in Dreamwod tech on Medium, where people are continuing the conversation by highlighting and responding to this story.