Forem: Monisnap

How we built a themeable multi-brand design system with Vue.js

Robin Lambell — Tue, 21 Jun 2022 09:00:43 +0000

At Monisnap our goal is to enable users to support their friends and family abroad by providing remittance services where traditional banking services are unavailable.

To this end, we build products under our own brand but we also have partners who leverage our expertise to enable their users to transfer money without the complexities that arise when dealing with multiple methods of international remittance.

In 2021 the front-end team at Monisnap built the Monisnap Interface Kit (Moniik for short). In the following article we’ll go over its creation, from the first meetings to the first projects in production.

For the sake of brevity we are focusing more on the process and reasoning rather than deep-diving the technical details but feel free to get in touch if your curiosity is piqued!

Why build a design system ?

The main reasons organizations decide to build a design system are myriad and well documented. For the team at Monisnap our top priorities were:

Enabling the tech team to deliver new products under the Monisnap brand in a small time frame while preserving the visual consistency of the Monisnap brand.
Delivering a complete turn-key remittance product to our partners with a short turn-around time. Our back-end services are stable and require only small configuration adjustments for new partners, we wanted an equally fast process for the front-end.

The kaleidoscope of design possibilities

The elephant in our design-system-room is of course the "themeable multi-brand" part. Our partners want a seamless experience when their users switch between the partner's main application and the Monisnap application. We need to make our product look and behave like our partner's and follow their brand guidelines.

But doesn't building a design system, without knowing the full extent of customization that will be required of it before-hand seem at odds with the basic idea of finding common patterns in designs, describing and re-using them?

Is Moniik really a bonafide design system? Maybe not, but we don’t get too hung up about it. We're happy with the productivity we've gained since and it's met our objective of cutting down on development time by orders of magnitude.

For example, here is the same recipient form themed for Monisnap and multiple partners. The screenshot below is from Figma, but with a handful of SASS variables we achieved the exact same thing in our production deployments.

Goyav, our first step towards a design system.

Before Moniik most of our front-end code was in a single git repository and we created a CSS-only toolkit we called Goyav that we applied to project components as needed.

This was a great first step towards outlining the components that would be most important to us in the future and thinking about how to make them generic enough for re-use. After several product launches and new partnerships however it became apparent that we were limited by a single repository.

We decided to split our front-end code into multiple repositories which lead us to reconsider how we shared common design elements and UI behaviors.

Design principals

The guiding principle was that of atomic design and we built up the different stages in the atomic design method as separate files: atoms, molecules and organisms.

We also decided to include an extra stage before the atoms: variables (also called Design Tokens). Colors, margins, borders, font-sizes are all set as overrideable SASS variables. These our the first step for customization for a partner.

Moniik doesn’t include template or page layout components, only some helpers. We were afraid that we would spend more time fighting against layout components, and reading their documentation than using the handful of helpers and variables you need for most layouts.

Getting the ball rolling

In the summer of 2021 we started testing several options for our design system. The only technical decision we made beforehand was to implement it with Vue.js (more on this later).

CSS Framework

We wanted to hit the ground running so opted to go with an existing SASS/CSS framework. The two contenders we tested exhaustively were Tailwind and Bulma. In the end Bulma fit our use case the best giving us base classes and helpers to build our components, but also allowing us to re-export them easily without the extra build step required by Tailwind.

Choosing Vue.js.

Vue.js SFCs (or Single File Components) and their surrounding ecosystem allow us to extend and override templates, scripts and styles in consumer projects with ease.

Although everyone on the team has more or less experience with the increasingly industry-standard React, we decided to go with Vue.js for the following reasons:

SFC’s allow us to swap-out or override styles quickly across a whole project
Vue.js templating system allows us to override components on a name by name basis. This becomes very useful when we want to replace a nested component. For example, we can swap out the <TextInput> component that is depended on by the <PhoneInput> component without reimplementing the whole <PhoneInput>
Nuxt.js is a great framework and does exactly what we need. SSG, SSR and SPA rendering are all supported.
Monisnap’s existing front-ends are written in Vue using Nuxt and everyone was satisfied with the experience so far.

However, Vue.js also comes with its fair share of challenges:

When we created Moniik (and arguably still today) Vue 2 is the most used version and until Nuxt 3 is released and stable we’ll be sticking with it, and missing out on many of the innovations of Vue 3.
Typescript support for Vue 2 and .vue files wasn’t stable enough to allow us to build with confidence. Notably absent at the time was a good solution for command line type checking and loading named exports. For this reason, and because of the relative simplicity of UI component logic compared to the rest of our front-end code, we decided to skip Typescript for now.

Developing Moniik

Development environment

Once we were set on technical choices, we built the development environment around the project.

Jest unit tests to avoid breaking changes in the components' public props and events API
Jest snapshot tests allow us to detect and avoid unwanted changes in the rendered HTML.
Storybook component tests & documentation. As static version of the storybook is also hosted on GitLab for easier references.
A sandbox project to play with multiple components in ways Storybook does not offer.
GitLab package registry publishing.

Component development

Over the next 8 weeks we developed the different components for the design system starting at the atomic level and working our way up to the organisms.

The pipeline we created that each component went through is illustrated by this diagram:

For each component we created a separate .js, .vue and .scss files, Storybook and Jest test files and TypeScript .d.ts declaration files.

After the intial HTML + SASS integration, we extracted most CSS property values to variables that can optionally be overriden in consumer projects:

@import '../../scss/variables';

// Control
$text-field-height: 58px !default;
$text-field-padding-top: 0 !default;
$text-field-icon-size: 24px !default;
$text-field-spacing: spacing(3) !default;
$text-field-font-size: 6 !default;

// Control Border
$text-field-border-radius: $radius-small !default;
$text-field-border-color: $grey-lighter !default;

First projects

Overlapping the end of the component development period, we started our first real project with Moniik. This was crucial to uncovering any issues that only arise when building products in the real world. We fixed some issues with tracking variables and some weird Nuxt compatibility bugs but integration was otherwise very smooth.

In December 2021 we started our first partner project and took three days to add their look and feel to Moniik. This was mainly due to adding SASS variables to values we didn't initially expect to have to modify.

In March 2022 we started our third partner project and with the increased maturity of Moniik’s code base, it took us a single afternoon to customize for our partner.

Moving forward

Moving forward we have the following challenges:

Better CSS loading: Within the given timeframe to develop the Design System we paid less attention to CSS performance than code clarity. There is a good amount of unused or redundant CSS that we would like to remove eventually.
The move to Vue 3 & TypeScript. Like many, we are huge fans of TypeScript and would love to have a homogenous TS codebase across all our projects.

We’re really happy with how Moniik has turned out and the projects it has allowed us to implement. We’re looking forward to building many more over the coming years while progressively improving the developer experience. If you would like to help us, take a look at our careers page

💡 Vue Typescript State Management : We can do better than “isLoading” in 2022

Julien — Tue, 04 Jan 2022 10:57:22 +0000

Sorry for the clickbait title, but I needed your attention 👀

Have you ever encountered code like this one :

new Vue({
  el: '#app',
  data () {
    return {
      info: null,
      loading: true,
      errored: false
    }
  },
  filters: {
    currencydecimal (value) {
      return value.toFixed(2)
    }
  },
  mounted () {
    axios
      .get('https://api.coindesk.com/v1/bpi/currentprice.json')
      .then(response => {
        this.info = response.data.bpi
      })
      .catch(error => {
        console.log(error)
        this.errored = true
      })
      .finally(() => this.loading = false)
  }
})

...

<div id="app">
  <h1>Bitcoin Price Index</h1>

  <section v-if="errored">
    <p>We're sorry, we're not able to retrieve this information at the moment, please try back later</p>
  </section>

  <section v-else>
    <div v-if="loading">Loading...</div>

    <div
      v-else
      v-for="currency in info"
      class="currency"
    >
      {{ currency.description }}:
      <span class="lighten">
        <span v-html="currency.symbol"></span>{{ currency.rate_float | currencydecimal }}
      </span>
    </div>

  </section>
</div>

It’s an example I found in the Vue documentation here https://vuejs.org/v2/cookbook/using-axios-to-consume-apis.html#Dealing-with-Errors

What if you have multiple things that could load, do you add a loading2 variable ? 👀

To solve this issue, you can use a variable for each async actions you have with this 4 “states” :

IDLE : the user didn’t trigger the action yet
WAITING : the action is ongoing
ERROR : there was an error
DONE : The action succeeded

Using an enum with the different states, and better naming, the code can be rewritten like this :

enum AsyncState {
  IDLE = 'IDLE',
  WAITING = 'WAITING',
  ERROR = 'ERROR',
  DONE = 'DONE',
}

new Vue({
  el: '#app',
  data () {
    return {
      info: null,

      AsyncState,
      currentPriceLoadState: AsyncState.WAITING,
    }
  },
  filters: {
    currencydecimal (value) {
      return value.toFixed(2)
    }
  },
  mounted () {
    axios
      .get('https://api.coindesk.com/v1/bpi/currentprice.json')
      .then(response => {
        this.info = response.data.bpi
        this.currentPriceLoadState = AsyncState.DONE
      })
      .catch(error => {
        console.log(error)
        this.currentPriceLoadState = AsyncState.ERROR
      })
  }
})

...

<div id="app">
  <h1>Bitcoin Price Index</h1>

  <div v-if="currentPriceLoadState === AsyncState.WAITING">Loading...</div>
  <section v-else-if="currentPriceLoadState === AsyncState.ERROR">
    <p>We're sorry, we're not able to retrieve this information at the moment, please try back later</p>
  </section>

  <section v-else>
    <div v-for="currency in info" class="currency">
      {{ currency.description }}:
      <span class="lighten">
        <span v-html="currency.symbol"></span>{{ currency.rate_float | currencydecimal }}
      </span>
    </div>

  </section>
</div>

With better naming and this simple enum, you can almost cover all the use cases where you need to load one or multiple things and manage errors ✨

If you want to manage different error messages, you can add another variable with an enum type like this :

enum CurrentPriceLoadErrors {
  INVALID_CURRENCY = 'INVALID_CURRENCY',
  API_LIMIT_REACHED = 'API_LIMIT_REACHED',
  DEFAULT = 'DEFAULT',
}

Tell me in the comment section if you like this trick or not, and if you have an even better technique !

And don’t forget to like and share this post if you liked it 💙

DON’T PANIC! Averting the DDOS crisis in under 5 minutes with Cloudflare

Maxence — Fri, 02 Jul 2021 09:42:22 +0000

As your business gains traction, your success will inevitably bring its share of malicious actors who will try everything to breach your systems and considerably slow down your operations.

One such threat are distributed denial-of-service (DDOS) attacks whereby the perpetrator floods a server with high network traffic loads coming from multiple sources, effectively disrupting the service and preventing legitimate users from accessing it.

Startups and SMEs are particularly exposed because they seldom have the resources to prepare for the unexpected and the impact of something seen as unlikely is often underestimated if not completely overlooked.

This guide will help you mitigate the risk in no time with a hassle-free, fully-managed and affordable solution.

Meet Cloudflare

Security can be tricky and requires extreme meticulousness. A system is only as strong as its weakest component, and the slightest negligence can lead to disastrous consequences.

Going managed can be a sensible choice if you are not positive you can handle security on your own. It ensures your infrastructure security is kept to the highest quality standards as new threats keep emerging.

Cloudflare offers a battle-tested DDOS protection service trusted by major companies throughout the world. The set-up can be done in a jiffy and their pricing plans start with a free tier.

How it works

Cloudflare acts as a gatekeeper between your server and the end-user trying to access it. It analyzes incoming requests and validates them against well-known threats and other inferences it has made over time from its experience of dealing with vast amounts of traffic worldwide.

You can choose how to deal with suspicious traffic, for example by presenting the user with a CAPTCHA or by blocking requests that match certain characteristics.

Setting up Cloudflare

When configured properly, transitioning to Cloudflare can be done without any downtime. Please make sure to understand every step perfectly and prepare a contingency plan before proceeding.

You will need to have editor access to your Domain Name Server (DNS), typically found on your registrar’s dashboard. You may determine your registrar via WHOIS.

Create a Cloudflare account
Once on the dashboard, proceed to adding your domain by clicking on “Add a Site”.
Select the plan that you deem best fit to your needs. DDOS protection is included in the free plan. Other plans typically feature additional optimizations (caching, image compression etc) and more responsive support.
List your DNS records (in layman’s terms, instructions about how to handle requests passing through your domain). Clouflare will automatically try to scan your current configuration. However, please make sure that it matches the configuration you see on your DNS. Add missing records manually if needed. At this point the cloud icons should be greyed out, meaning Cloudflare is not yet proxying the traffic. You may skip the next screen about changing your nameserver for now; we’ll get back to it later.
IMPORTANT - Before moving on to the next steps, make sure to whitelist IP addresses necessary for the proper functioning of your service (typically those of other microservices or partners it needs to communicate with). Failing to do so might disrupt your services. To do so, head over to the “Firewall > Tools” section and add the set of IP addresses to allow.
Now you’ll need to configure your DNS to point to the Cloudflare servers. This step might vary depending on your registrar (or DNS provider), but the interface should look similar. For example on Namecheap, you will need to switch to “Custom DNS” and replace the existing nameservers with Cloudflare’s.

Cloudflare’s nameservers you should be pointed at can be found in the “Overview” section (the values may differ from the ones in the screenshot).

The new DNS configuration takes some time to propagate (from a few minutes up to a couple of hours depending on your registrar).
At this point you’re ready to activate Cloudflare. Until now, traffic was rerouted directly onto your servers without any filtering. Turning on Cloudflare’s proxy on the DNS records you listed in step 4 will effectively activate the protection. This is the step where it all comes together. Make sure everything is correct for the umpteenth time before proceeding. Once you are confident, head over to the “DNS” section and turn on the proxy on all the records. Cloud icons should now appear orange, meaning the DNS record is properly proxied by Cloudflare. If anything were to go wrong at this stage, immediately turn off the proxy on every DNS record.
You are almost done. Until now, your server’s IP address was directly exposed to the public. Cloudflare adds a new layer on top of your server and obfuscates its IP address to new users. However the original IP address is still accessible, and Cloudflare cannot do anything to protect you from direct-access attacks. A good strategy is to configure your server to only accept requests forwarded by Cloudflare. Additionally you might want to allocate a new IP address to your server for good measure.
Congratulations! You made it through and your server is now protected against DDOS attacks.

Please let me know if you run into any problems or if you’re interested in diving deeper into the subject. Cloudflare offers many more features you might be interested in such as caching and compression which can improve performance and eventually save money.

🚀 Flutter CI/CD using Git Tags in 5 minutes

Julien — Fri, 14 May 2021 09:50:20 +0000

What you will need
What you will do
Step 1: Deployment script
Step 2: Git push with tag

What you will need

📲 A Flutter app (obviously)
📦 A Github, Gitlab or Bitbucket account
✨ A Codemagic account (linked to your app repository)
😁 Your best smile

What you will do

You will create a git tag containing your new app version, then push it to your repository. It will automatically trigger a Codemagic build, and release your app on the Play Store 🚀

Step 1: Create a deployment script 🛠

Below you'll find code to configure the CI/CD. You just have to add it to the root of your repository in a file named codemagic.yaml
I've used a script instead of the workflow editor (Codemagic GUI) for multiple reasons (versioned, faster...) but mainly because the version handling isn't possible using the editor.

# codemagic.yaml

# ... <- Here you will include the "reusable" parts that are described afterward

workflows:
  play-store:
    name: Play Store Release
    max_build_duration: 30
    cache: *caching

    environment:
      flutter: *flutter_version
      xcode: latest
      cocoapods: default
      vars:
        <<: *gcp_service_credentials
        <<: *keystore_release

    # ! THE IMPORTANT PART IS HERE !
    triggering:
      events:
        - tag
      branch_patterns:
        - pattern: "master"
          include: true
          source: true
      tag_patterns:
        - pattern: "*"
          include: true

    scripts:
      - *android_key_properties_setup
      - *flutter_android_properties_setup
      - *flutter_pub_get
      - *flutter_test
      - *flutter_build_play_store_release

    artifacts:      
      - build/**/outputs/**/*.aab

    publishing:
      google_play:
        credentials: *play_console_credentials
        track: alpha
        in_app_update_priority: 0

Next are the reusable parts, to be clean and not repeat yourself ✨. Replace the encrypted variables using your credentials and the Codemagic encrypting tool.

# codemagic.yaml

reusable:
  flutter_version: &flutter_version 1.22.6

  environment-variables:
    - &keystore_release
      FCI_KEYSTORE_PATH: /tmp/keystore.keystore
      FCI_KEYSTORE: Encrypted(...)
      FCI_KEYSTORE_PASSWORD: Encrypted(...)
      FCI_KEY_PASSWORD: Encrypted(...)
      FCI_KEY_ALIAS: Encrypted(...)

    - &gcp_service_credentials
      GCLOUD_SERVICE_ACCOUNT_CREDENTIALS: Encrypted(...)      

    - &play_console_credentials Encrypted(...)

  scripts:
    - &android_key_properties_setup
      name: Android - Setup key.properties
      script: |
        echo $FCI_KEYSTORE | base64 --decode > $FCI_KEYSTORE_PATH
        cat >> "$FCI_BUILD_DIR/android/key.properties" <<EOF
        storePassword=$FCI_KEYSTORE_PASSWORD
        keyPassword=$FCI_KEY_PASSWORD
        keyAlias=$FCI_KEY_ALIAS
        storeFile=/tmp/keystore.keystore
        EOF

    - &flutter_android_properties_setup
      name: Flutter x Android - Setup local.properties
      script: echo "flutter.sdk=$HOME/programs/flutter" > "$FCI_BUILD_DIR/android/local.properties"

    - &flutter_pub_get
      name: Flutter - Get dependencies
      script: flutter packages pub get

    - &flutter_test
      name: Flutter - Run tests
      script: flutter test --machine

    # ! THE IMPORTANT PART IS HERE !
    - &flutter_build_play_store_release
      name: Build AAB for Play Store release
      script: |
        GCLOUD_SERVICE_ACCOUNT_CREDENTIALS=$(echo $GCLOUD_SERVICE_ACCOUNT_CREDENTIALS | base64 --decode)
        NEW_BUILD_NUMBER=$(($(google-play get-latest-build-number --package-name 'com.company.example') + 1))
        NEW_VERSION_NAME=$(git describe --tags)

        echo $NEW_VERSION_NAME
        echo $NEW_BUILD_NUMBER

        flutter build appbundle --build-name=$NEW_VERSION_NAME --build-number=$NEW_BUILD_NUMBER  --obfuscate --split-debug-info=$FCI_BUILD_DIR/debug_files

  caching: &caching
    cache_paths:
      - $HOME/.gradle/caches
      - $FLUTTER_ROOT/.pub-cache

# ... <- The workflow part described before should be here

In the previous script, the "flutter_build_play_store_release" script handle the versioning :

Version is retrieved from the tag.
Build number is retrieved from the play console (fetching the highest build number, and incrementing it for this release).

Don't forget to replace com.company.example with your app package name

You can now push this script onto your repository. It should then be visible from Codemagic and you should be able to trigger it manually.

Step 2: Add git tag 🔖 -> push it 🚀

Creating a git tag is very easy. We will use 1.0.0 as our version, and tag.
You just have to run the following commands :

git tag -a 1.0.0 -m "Release 1.0.0"
git push origin 1.0.0

That's it! You should see a build running in Codemagic 🏄‍♂️

What's next?

You can add as many workflows as you want using Codemagic! You can use the GUI editor, and then extract to code to have more control over the code.

Here we deploy on Alpha, so you can change to Production when you feel ready. And then, you can add an iOS workflow with mostly the same code.

Leave a comment, a like or even a unicorn 🦄 if you've achieved this tutorial! 🚀🔖

Universal Apps on Serverless ? Yes.

Jason — Wed, 08 Jul 2020 12:55:54 +0000

Introduction

The serverless architecture might be one of the most trending tech paradigms nowadays.
It has been popularized by AWS with its “AWS Lambda platform” and powers millions of APIs worldwide.

We have been using it at Monisnap for the past year on our micro-services architecture and it has been a blast !
Now, imagine if you could also power your front end apps ( mostly Universal Apps ) with a serverless architecture ?
Sounds great, right ?

Why serverless ?

You might ask, “Why would I want to do that ? I could just use a static assets provider like Netlify or a good ol’ server running on a vm on the cloud ! ”.

Yes you could but there are a few drawbacks :

A static assets provider is very useful when you have only a few pages to serve ( or do not care about SEO and just use SPAs ) but imagine if you have millions of generated pages, it is just not imaginable to generate all of them before deployment.
Running on a server works and has been proven to be quite effective in the past ( and still is to some extent ) but we can do differently now and particularly way cheaper :).

The serverless paradigm gives us a lot of pros but also cons. I’m not gonna get into details about them as it is not the subject of this article but here is a pretty good overview by Cloudflare.

You can use any Front-end framework ( or an homemade one ) as long as it allows some kind of programmatic function to be plugged into a node framework / server ( e.g Express ).

You also need your serverless provider to support returning binary types ( as we will be returning html, js , css, etc.. files.

At Monisnap we use NuxtJS, the Serverless framework and AWS lambda as our serverless provider.

This is what we're going to cover today :)

Getting Started

( I’m gonna assume you have at least NodeJS installed :) )

First we will need some dependencies to make it work on a serverless environments :

npm install -S serverless-http express serverless-apigw-binary

Now we are going to init a new NuxtJS project ( Choose the options that suit your needs when asked ) :

npx create-nuxt-app hello-world

Now cd into the directory :

cd hello-world

And then start the project :

npm run dev

You should see this if you go to http://localhost:3000/ on your web browser :)

The 'Server' code

Now to make it runnable on our “custom” server, we are going to create a folder “server” at the root of the project and create a new file “index.js” inside it.

index.js

The configuration is pretty straightforward.

We first import the required dependencies :

const path = require("path");
const { loadNuxt } = require("nuxt");
const serverless = require("serverless-http");
const express = require("express");

Then we init the express app :

const app = express();

Next we have the module.exports.nuxt which export the "handler" function that is going to be used by serverless.

Inside this export we have the first app.use which links the static assets from the directory where the assets are built to the /_nuxt/ path ( this is the default path where Nuxt looks for the assets ) :

app.use("/_nuxt", express.static(path.join(__dirname, ".nuxt", "dist", "client")));

We then get the Nuxt instance ( start indicates that we want to use the production package ) :

const nuxt = await loadNuxt("start");

And we tell express to use it for every routes via the nuxt.render method which allows us to render each route based on our routes params, pretty useful.

app.use(nuxt.render);

In the last part we use the serverless-http package which will wrap our Express app to be understandable by Lambda. We also need to pass some configuration options to allow any content-type we wish to serve with our application :

return serverless(app, {
   binary: [
     'application/javascript',
     'application/json',
     'application/octet-stream',
     'application/xml',
     'font/eot',
     'font/opentype',
     'font/otf',
     'image/jpeg',
     'image/png',
     'image/svg+xml',
     'text/comma-separated-values',
     'text/css',
     'text/html',
     'text/javascript',
     'text/plain',
     'text/text',
     'text/xml',
     'font/woff',
     'font/woff2'
   ]
 })(request, context)
}

And this is it for the server code ! ( pretty easy right ? :))

The Serverless part

Now let’s focus on the Serverless part.
Create a the root of the directory a file named serverless.yml.

serverless.yml

This is a pretty basic Serverless configuration :

First we define the service name ( used by lambda and API Gateway ) :

service: hello-world

Then we have the provider specific configurations :

The provider name ( AWS in our case ),
The nodejs runtime we want our code to run on
The AWS lambda region where our lambdas will we provided

provider:
  name: aws
  runtime: nodejs12.x
  region: eu-west-1

We then have a custom variable set called apigwBinary which will be used by the plugin serverless-apigw-binary to let API Gateway know that we want to support binaries as responses.

custom:
  apigwBinary:
    types:
      - "*/*"

The next block define our function and the associated http events, we set two event, one will be handling all the requests from the root path and the other any additional path we want to support.

functions:
  nuxt:
    handler: server/index.nuxt
    memorySize: 512
    events:
      - http:
          path: /
          method: any
      - http:
          path: /{proxy+}
          method: any

And finally we tell Serverless we want to use the serverless-apigw-binary plugin :)

plugins:
 - serverless-apigw-binary

Before deploying the app, you need to have an account ( you can create one for free here) and set up the AWS cli tool ( you can use the free tier with lambdas )

Once you’ve configured the cli tool, you are ready to build and deploy the app :

npm run build && sls deploy

And you can now hit the url shown in the console output and you should see your Nuxt app appearing :)

https://<api-gateway-id>.execute-api.<region>.amazonaws.com/dev/

There is a little caveat though... If you check your web browser console you should see a lot of console errors related to the loading of resources.
Nuxt tries to load them from the /_nuxt/ path but API gateway exposes the lambda with a “stage” prefix ( e.g dev ), so obviously it does not find them.

To effectively fix this problem, you need to add a custom domain name to API gateway ( You will need a domain name and a tls certificate ) which will allow you to serve the app from the root of your domain.

Conclusion

Serverless allows us to compile and serve our Nuxt application at a very low cost and with no worries about scalability ( among other benefits ).
Of course it comes with some drawbacks which can easily be overcome.

Drop a comment if this has been useful or if you have any questions :)

Have a good one !

5 min TypeScript NPM package

Jason — Fri, 14 Feb 2020 15:40:41 +0000

Introduction

As developers we might want to create a new framework or package reusables components, functions, etc...
Hopefully as JavaScript developers we have a NPM !

We may be also using TypeScript to add a layer of safety on top of Javascript plus a more advanced OOP design

So what about we create a NPM package which will be available to
JavaScript projects but most importantly Typescript projects ?

Let's go and let's see how we do it at Monisnap !

Getting Started

( I assume you have NodeJS and Typescript installed )

First create a new folder and open a terminal tab and type :

npm init -y

This will basically initialize your npm package by creating a package.json with some default options ( we will get back to that later )

and

tsc --init

This also initialize the project to use TypeScript by creating a tsconfig.json which holds important options defining how your TypeScript code will be handled.

So now you should have this :

Good ? next !

Now we can write some code :)

Create a "src" folder and two files inside it "index.ts" and "unicorn.ts" ( yes I like unicorns )

unicorn.ts

export class Unicorn {
  public sayHelloTo(name: string): string {
    return `🦄 Hello ${name} !`;
  }
}

index.ts

export * from "./unicorn";

We now need to edit the tsconfig.json ( copy / paste the following )

{
  "compilerOptions": {
    "declaration": true,
    "strictNullChecks": true,
    "target": "es5", 
    "outDir": "dist",
    "module": "commonjs",
    "moduleResolution": "node",
    "sourceMap": true,
    "lib": ["es2015", "dom"],
    "rootDir": "src"
  },
  "include": ["src"],
  "exclude": ["node_modules", "dist"]
}

let's cover the important options :

declaration: It tells typescript to generate the typings ( important if we want some "automatic" docs for our code
target: specify the ES target version ( I chose ES5 here because I target nodeJS )
outDir: The compiled files destination
module / module resolution: I use commonJS / nodeJS as its the module system on NodeJS
sourceMap: Important if you want the source map to be able to debug Typescript code directly
rootDir: The root folder where our code is.

Now we can edit the package.json :

{
  "name": "unicorn-says-hello-world",
  "version": "1.0.0",
  "description": "A unicorn that says hello world",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "files": [
    "dist"
  ],
  "scripts": {
    "build": "tsc",
    "prepare": "npm run build"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/monisnap-jason/unicorn-says-hello-world.git"
  },
  "keywords": [],
  "author": "monisnap-jason",
  "license": "ISC"
}

Again the important options:

name: the name of your package on NPM
main: the entry point ( our code will be compiled in the dist folder )
types: the path of our code typings
files: The files we want to include in our package
scripts:
- build: tsc to compile our code
- prepare: this is a NPM hook which executes a command before publishing to npm ( we tell it the execute the build command above )
repository: the options about the repository which holds the package code

We also need a .gitignore file ( as we don't want to include some folders into our repository ):

\dist
\node_modules

And lastly you can create README.md to tell the world how to use your package.

We're almost done !

Now the final touch :

npm publish

you should see this in your terminal output :
"+ your-package-name@1.0.0"

And voilà your package is on NPM
here is mine for reference unicorn-says-hello-world

Now if I want to use my brand new package I just to need npm install unicorn-says-hello-world in a new or existing project, and I can use it like that :

Drop a comment below if you have any questions !

Have a good one :)

🔎🔍 AWS Cloudwatch - Top 5 things you need to know

Edouard Le Juge — Fri, 31 Jan 2020 16:35:54 +0000

If you can rely on your logging, monitoring and alerts you'll be free to code fearless, how does that look?

At Monisnap our entire backend is built using AWS features like API Gateway, Lambdas, SQS, SNS... It made sense for us to use Cloudwatch as our monitoring system. In this article I will share with you a few tricks I use within cloudwatch. Nothing fancy at all, just the basics, enough to feel the power of cloudwatch and find what you are looking for.

📖 Search through your logs in cloudwatch

Before we dig in the log search itself I would like to advice any of you to always log JSON objects instead of plain text. You can grep for texts in strings but you loose the power of more specific filtering, grouping or sorts that will get your logging game to the next level.

📃 Search a specific log group

If you go to a specific log group, either a log group that you created yourself or from a specific lambda, click on the 'Search Log group' button. You will now be able to search in all the log streams within this log group.

Let's now dive into how to filter those logs.

✅ Find specific value, or filter out a specific value

Looking for ERROR lines? You could just type ERROR in the search bar. But, as a reflex I always use the double quotes "ERROR", in case the value I am looking for has a '-' or any possible interpreted character.

    "ERROR"

What will the '-' could do to my search? It would filter it out. If you don't want all the 'INFO' logs, you could simply do this:

    -"INFO"

✅✅ Find specific values (AND)

You now want all the ERRORs from the requestId 'c8ae6b2c-1750-4f5d-bfda-14403cb978a0' but without the ones from a 'NotImportantException'. In that case you can just put the seraching operation one after the other:

"ERROR" "c8ae6b2c-1750-4f5d-bfda-14403cb978a0" -"NotImportantException"

✅🔘 Find one of the values (OR)

If you want to have all the logs with ERROR or WARN, you can use the question mark as a OR operator. In our case this search would like like this:

?"ERROR" ?"WARN"

Note: I haven't find a way to filter using both AND and OR together. If you know how, please leave your trick in the comments section below and I will add it to my article so the entire community can benefit from your wiseness :)

⎨⎬ Search on JSON attributes

If, as a smart logger, you are using JSON objects and not plain text you can now apply those filters on specific attributes of your object using the {$.} notation. {} means that you will be searching on the object itself and $. is the root of your logged object. the OR operator will now be '||', and, you guessed it, the AND will be '&&''

Example: If you have the following logs:

    A {"line": 'first', "type": "1"}
    B {"line": 'second', "type": "2"}
    C {"line": 'third' , "type": "3"}

Let's see some example here:

{$.line="first" || $.line="second"}
 -> Returns line A and B.

{$.type>2}          
 -> Returns line C. 

{$.line="first" && $.type!=3}
-> Returns line A.

I will let you play with this and query for more complex object with a list maybe? Something in that taste:

{$.type.subtype[0].value=1}>

🕵️‍♀️ Insights

Now that you are able to find logs in a specific log group, let's explore the power of the Insight feature that AWS offers. Insight let you run search among several log groups in a query like fashion. Yes, you will now be able to sort, group and all.

First of all, go to you cloudwatch UI, click on Insight menu on the left of the screen. You will end up with an empty log group bar and a basic query.

Add the log group(s) you want to run query on. A specific lambda is totally fine for now. Once you have selected the log group(s) you want to run queries on, you will be able to see on the right side of your screen all the commands and fields that you can play out with.
I will, in this article, only go through the basic ones. We just want to get a taste of what are the possibilties here. For now, we will only look into the commands: fields, filter, sort, and limit. I invite you to look into stats and parse though, very powerful features !!

All the commands that you will add in the query will be treated one after the other. It's a suite of pipe operations.

📝 Fields

It kind of speaks for itself: the list of fields you want to have the value of in the output of the pipe operation. If you want to see all the fields you have access to, run the basic query that Insight gives you and you will see a lot more in the Discovered fields on the right side of the screen.

fields @timestamp, @message, @requestId

🛃 Filter

Pretty obvious as well, this will filter the logs as needed. If you want all the logs of the requestId '':

fields @timestamp, @message
    | filter @requestId='47dbd193-c8ad-47b5-8668-6045668ce472'

Among those logs, only the line with our own logType set to WARN OR ERROR are interesting to you? You can use the 'like' operator to apply a new filter on the result of the previous pipe operation. 'like' operator uses the regex synthax to filter.

fields @timestamp, @message
    | filter @requestId='47dbd193-c8ad-47b5-8668-6045668ce472' 
    | filter logType like /(ERROR|WARN)/

🔻 Sort

If you want to see the latest ERRORs that happend on this (or these) log group(s) you can apply a sort operation to the mix and use it on timestamp field. ASC and DESC sort types are allowed.

fields @timestamp, @message
    | filter logType like /ERROR/
    | sort @timestamp desc

⇥ Limit

Too many results? limit the number of results you want in you result by using the limit operator and only show the last 10 ones:

fields @timestamp, @message
    | filter logType like /ERROR/
    | sort @timestamp desc
    | limit 10

👨‍🚒 Dashboards

Cloudwatch also gives you the ability to gather in one place all the monitoring you feel you should be keeping an eye on. Those dashboards can, not only contain result from log queries that we saw in the section above but also aggregate values of operations on your API gateway, SQS queues, S3 files and much more.

In our team we have several type of dashboards:

👨‍⚕️ Regular monitoring

For health monitoring purpose we have a few general dashboards, general monitoring showing 2XX, 4XX, 5XX and other HTTP codes we want to monitor. A tailing of the latest errors. Anything that could give us a feel of what is going on on our system. And what would show us that something is odd right away. Nothing fancy, just enough to notice and diagnose where the blood is coming from if we have alerts firing.

👩‍🔧 Specific features monitoring

For any impactful feature we try our best to add graphs or tailing logs that can monitor the impact of the feature by tracking a specific KPI. It can totally be a specific log nomenclature that we can track for a certain amount of time.

Example:

On a recurring error from a partner we added the specific log "error 0234 occurred"
We created a query that populate a graph based on it
We confirmed based on this that the impact of this specific error was pretty bad
We implemented the ability to recover from that issue
We added in our code a new log saying "recovered from error 0234"
Created a new query to monitor this implementation
We are now able to monitor how many requests got recovered from this specific error or not.
close the bug if the fix stopped our problem

🚨 Alarms

Last but not least in our article is the ability to set Alerts using the very helpful Alarms feature Cloudwatch gives us. You can set Alerts on any of your AWS resources: API gateway, SQS, lamdbas and many more.

⏰ Create an alarm

To add an Alert simply go to the Alarms menu on the left side menu. Click on the 'create alarm' red button.

📈Choose your metric

You will then be asked to select the metric(s) on which you want your alarm to be set on. A metric is usually a combinaison of an object (api gateway endpoint, lambda function, sqs topic...) and an operation on it (sum of execution, sum of errors, number of deletion, average duration...)

You might have to apply your alerts based on a duration type on a period, per second, per minutes, per 5 minutes...

📛Threshold type

Two type of threshold can then be applied: a static number reached, or an anomaly gets detected. We only have used the static alerts for now and it is quite straight forward, you set the value above/under which you want to receive an alert. The anomaly type applies an algorithm on how the metric you used is evolving through time. If the value evolves in what the algorithm find abnormal it will trigger your notification. Feel free to share your thoughts and experience of this feature in the comments if you have been playing with this. It would be much appreciated !!!

☎ Action

Here you can select how you want to be notified. We usually use a SNS topic which will be sending an email to our developers email address. But it is up to you to set up as you see fit.

🤓 Review and confirm

You will have to simply set the name and description of your alarm. click confirm and you are good to go !

Conclusion

We only scratch the surface of what Cloudwatch can offer in this article but I think we covered here all the parts that you have to know for a basic monitoring and debugging skills.
I hope it helped you having an overview of what AWS gives you in the monitoring world. We have been using it for 6 months at Monisnap and haven't been blocked by anything serious so far. Hope you'll be using it soon, it's a great tool box to play with !!!!

Hide your f🤬🤬king API keys and credentials from versioned code

Jonathan BROSSARD — Fri, 24 Jan 2020 11:09:02 +0000

As a developer, you deal every day with API keys, passwords, credentials, tokens etc... and you do NOT want to share them.

Here are the different ways to handle them :

1 - A versioned settings file with secrets in it.
If you do that, please continue to read this post, internets need that.

2 - A non versioned settings file.
Better ! But when you'll onboard developers, it will be funny to check how you'll send them these values.

3 - Environments variables (the classic .env) !
Yeah ! Even better. Once again, how your future team members will have their own, by copy pasting yours ?

4 - Store your secret into a secret management service !!!
Yeah ! OK, let's see how to do so

There are several secrets management tools, but, I'll talk about the one I know best, because this is the one we're using at Monisnap : AWS Secret Manager.

What is AWS Secret Manager ?

AWS Secrets Manager is a secrets management service which enables you to easily rotate, manage, and retrieve credentials, API keys, or other secrets.
Using Secrets Manager, you can secure, audit, and manage secrets used to access your resources.

You'll now be able to share your code (every file, every line), without any fear. Indeed, in your code, there will only be specific strings which describes your secrets, but not the secrets values themself.

Before Secrets Manager	After Secrets Manager
`db-name.cluster-cifkjshyfli1p.eu-west-2.rds.amazonaws.com.`	`DB_HOST`
`username`	`DB_USER`
`password`	`DB_PASSWORD`

Security

AWS Secrets Manager automatically rotates your secrets. Your teammates or anyone else who clone/fork your code can have access without any knowledge on what are the secrets values.

You only need to manage ACL via AWS IAM.

And so, for instance, your seniors developers can have access through their IAM roles and create/edit/update/delete new secrets, and interns can't.

Usage

For every AWS Cloud based infrastructure, all you need to do is to grant access to the secrets.

Our MicroServices infrastructure is built on Serverless lambdas functions, so we just have to add the rights IAM roles to our lambdas.

Also, you can easily split them by environments.

provider:
  name: aws
  runtime: nodejs10.x
  stage: ${opt:stage, 'dev'}
  region: eu-west-1

  iamRoleStatements:
    # Role for using AWS Secret Manager
    - Effect: "Allow"
      Action:
        - "secretsmanager:GetSecretValue"
      Resource: 
        - ${self:custom.jarvisAdminPassword.${self:provider.stage}}

  environment:
    JARVIS_ADMIN_PASSWORD: ${self:custom.jarvisAdminPassword.${self:provider.stage}}

custom:
  stage: "${opt:stage, self:provider.stage}"

  jarvisAdminPassword:
    local: "local_jarvis_admin_password_secrets_key"
    dev: "dev_jarvis_admin_password_secrets_key"
    staging: "staging_jarvis_admin_password_secrets_key"
    prod: "prod_jarvis_admin_password_secrets_key"

An extra cool thing about secrets: if you need to update your database accesses, an API key or any secret value you can just update the secret value into your Secret Manager, and every services that are using it will be automatically updated :)

Hope it helps !

⏱ 5 min chrono FREE admin panel with ForestAdmin

Julien — Fri, 17 Jan 2020 11:15:17 +0000

Product guy : Hey, could you give me access to database ?

Tech guy : Hmm.. why ?

Product guy : To avoid to bother you each time I need to update something

Tech guy : So, you would need a BackOffice for that.

Product guy : Ok, could you please develop it ?

You probably already had this discussion...
Let's imagine now that you can solve it ... in MINUTES !

What is ForestAdmin 🌲 ?

"Forest Admin provides an off-the-shelf admin panel based on a highly-extensible API hosted on your servers."

In other words, it's a SaaS platform providing all common admin tasks you'll need as developer if you want to create your own Back Office.

With Forest you can :

📝 View / Create / Edit / Delete entries of your database
🔐 Handle access control list
📈 Create awesome dashboards and views with 0 or few code lines.
🌍 Create custom actions that triggers your backend API
✨ And many more !

All of this only with configurations and few lines of Javascript 👨‍💻!

Here is an example of what it looks like out of the box :

Installation

Create your account for FREE at https://www.forestadmin.com/
Follow the instructions provided to connect to your database*
Install in local using Docker or Node.js
npm start 🚀
Go to http://app.forestadmin.com/projects

*For the time being, you can only connect to Mysql, PostgreSQL, SQL Server and MongoDB.

Deployment

You can host your server anywhere you want using Docker or Node.js. For example, Forest provide a tutorial to host your server on Heroku here (it takes really 3 minutes !)

Customization

You have 2 categories of customization :

Model : You can modify your database model, relationships and custom actions (called "smart actions") using Javascript !
UI : That's the best part for developers. You can modify your UI using the GUI layout editor provided by forest admin (based on ember.js)

Here are some examples :

You can even develop your own UI with HTML/CSS/JS code to have custom views like this one :

How it works ?

It's quite interesting to know how the product is made because it's atypical. Indeed, the code and model is hosted on your servers but the UI layout configuration is hosted on Forest servers. Here is a schema of the architecture :

This way, your data remain secure 🔐

Conclusion

It's been 6 months that we use Forest and the whole team is very happy with it. The product and marketing love the dashboard and custom views (you know, they love fancy graphs 😄). The customer support work is easier thanks to views displaying customer data to answer questions quickly.

Also, it's free up to 10 users so you can test it before using it in your profesional projects !

And above all, it doesn't take time to your dev team, and they can use time for "real work" ^^

Hope it helps !

Bye bye Postman ! Let's share your REST API calls in team, easily !

Jonathan BROSSARD — Fri, 10 Jan 2020 10:56:48 +0000

As developer, we are using tools to make REST API calls (Postman, Insomnia, PostWoman...), and these tools are very usefull.

The limits

Make calls to test an API is fine, but if you want to edit, version, or simply share it with your team ... it's not very handy.

Indeed, you can use Postman paid plans for instance, but it means that you need to pay, and it means that all your team needs to use Postman, again one more tool...

Do you know REST Client ?

REST Client* is a VS Code extension.

It will let you to send HTTP requests and view responses into VS Code. And only based on a text file, which can easily be versioned among your repository. 🙏

Pros

The main advantage is to be able to version and share your API calls.

If you're working on an internal API, you may want to share how to test a new endpoint with your colleagues.

REST Client is a good easy way to do it !

Another good point is simplicity. All you need to do/have, is ONE file. Also, if you jump between projects and do not remember how works an API/Service on which you did not work since a while, just look at this file !

Cons

You have to use VS Code... but for a lot of known reasons among internets, you are using Emacs, VI, or VS Code 😄

What's next ?

Here is how to begin.

The file

Only create a file with .http extension, for instance doc.http

And then, VS Code will show you the file as :

And by clicking on "Send Request", a new tab with all request response details will be opened.

Go further

You may also use environment variables to easily switch between you env and avoid any api-key or token manually update in the file, or url update etc...

Here is how to use environment variables, just like that :

Here, I created 4 environments : local, dev, staging, production.

These 4 environments have their own host and token variables, with their specific values.
But they also share a variable, named partnerUniqueToken (don't ask me why ... too many partners don't have several env...).

Hope it helps !

Big up to Julien who discovered this extension !

Github private package with CI/CD

Julien — Fri, 03 Jan 2020 12:33:28 +0000

With the newly created Github Package Registry, you can store your private packages in the same place as your code.

Deploying packages and use them inside a package.json file is very simple. When it comes to use them in a CI/CD environment it's a bit tricky.

First, we need to provide our ci/cd environment a secure way to retrieve packages from our private repositories. Using the classic npm login is secure but not very handy. So the TOKEN approach is what I chose. See more info about creation here. You only need to provide read access to packages.

Then we need to set a reference to our private repositories for npm to resolve and find it. The easiest way is to set an .npmrc file at the root of your project and put things this way :

registry=https://registry.npmjs.org/
@owner:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}

The trick here is to indicate the default registry (registry.npmjs.org) for all other public packages you want to use.

Be sure to replace owner by your organisation name. The GITHUB_TOKEN is stored as environment variable (you have many ways to hide it on your machine and in some ci/cd tools, don't need to hardcode it).

Hope it helps !

Forem: Monisnap

How we built a themeable multi-brand design system with Vue.js

Why build a design system ?

The kaleidoscope of design possibilities

Goyav, our first step towards a design system.

Design principals

Getting the ball rolling

CSS Framework

Choosing Vue.js.

Developing Moniik

Development environment

Component development

First projects

Moving forward

💡 Vue Typescript State Management : We can do better than “isLoading” in 2022

DON’T PANIC! Averting the DDOS crisis in under 5 minutes with Cloudflare

Meet Cloudflare

How it works

Setting up Cloudflare

🚀 Flutter CI/CD using Git Tags in 5 minutes

Table of contents

What you will need

What you will do

Step 1: Create a deployment script 🛠

Step 2: Add git tag 🔖 -> push it 🚀

What's next?

Universal Apps on Serverless ? Yes.

Introduction

Why serverless ?

Getting Started

The 'Server' code

The Serverless part

Conclusion

5 min TypeScript NPM package

Introduction

Getting Started

🔎🔍 AWS Cloudwatch - Top 5 things you need to know

📖 Search through your logs in cloudwatch

📃 Search a specific log group

✅ Find specific value, or filter out a specific value

✅✅ Find specific values (AND)

✅🔘 Find one of the values (OR)

⎨⎬ Search on JSON attributes

🕵️‍♀️ Insights

📝 Fields

🛃 Filter

🔻 Sort

⇥ Limit

👨‍🚒 Dashboards

👨‍⚕️ Regular monitoring

👩‍🔧 Specific features monitoring

🚨 Alarms

⏰ Create an alarm

📈Choose your metric

📛Threshold type

☎ Action

🤓 Review and confirm

Conclusion

Hide your f🤬🤬king API keys and credentials from versioned code

What is AWS Secret Manager ?

Security

Usage

⏱ 5 min chrono FREE admin panel with ForestAdmin

What is ForestAdmin 🌲 ?

Installation

Deployment

Customization

How it works ?

Conclusion

Bye bye Postman ! Let's share your REST API calls in team, easily !

The limits

Do you know REST Client ?

Pros

Cons

What's next ?

The file

Go further

Big up to Julien who discovered this extension !

Github private package with CI/CD