DEV Community: Geoffroy Empain

Shipping Jamstack like a hero - beware, it's cool

Geoffroy Empain — Mon, 25 Jan 2021 16:23:20 +0000

So you love React, Angular, Vue, Gatsby and other Jamstack frameworks ? Hooray, I do too 🎉

But.... we've all had these issues:

How do I deploy ? With Netlify, Docker, or a good old HTTP server ? 🤔
When I need to change my API URL... I have to rebuild and re-deploy 😞
When I need to preview a small change... re-deploying takes forever 😞
Managing SSL certificates is a pain. It should be automatic when I ship a new site 😡

The solution: Meli, a self-hosted platform built on top of the well-known Caddy Server. Out of the box, you get automatic HTTPs, zero-downtime, and heavy-duty performance.

I've installed Meli on my VPS, so I'll skip this part which takes about 2 minutes with Docker Compose, but checkout the docs for instructions. From here, I'll assume you've installed Meli at https://meli.company.com.

Deploying a site to Meli

Let's start with a very simple site, dist/index.html

<!doctype html>
<html lang="en">
<head>
    <title>Meli example Vue.js app</title>
</head>
<body>
Hello !
</body>
</html>

Once logged in to your Meli instance:

create a site named hello
get your site ID
get your upload token
upload your site

npx @getmeli/cli upload \
   ./dist \
    --url http://localhost:80 \
    --site "8f30f74f-4b63-4dc3-b8dc-788ca43740a8" \
    --token <site-token> \
    --branch "latest"

Your site is now available at https://hello.meli.company.com 🚀

Serve your site at https://hello.com

Okay, I'll agree, https://hello.meli.company.com isn't really sexy. We want our awesome site to be served at https://hello.com. To do this:

In your Meli site, configure a custom domain with hello.com
In the DNS zone of hello.com, add an A record that points the IP of meli.company.com. For subdomains like sub.hello.com, you can use a CNAME record that points to hello.meli.domain.com only when it is the single record (all types combined) configured for that subdomain.
Browse https://hello.com, and off you go !

Deploying to Meli from your CI

You can also automatically deploy when you push to your Git repository. For example, with Github Actions:

name: main
on: [ push ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: '12'
      - name: "publish"
        run: |
          npx @getmeli/cli@next upload \
            ./dist \
            --url "https://meli.domain.com" \
            --site "<your-site-id>" \
            --token "$MELI_TOKEN"
        env:
          MELI_TOKEN: ${{ secrets.MELI_TOKEN }}
          # using default GITHUB_TOKEN set by Github Actions
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Note that --branch is not used here, it is auto-detected by the Meli CLI.

With this setup, you'll get pull request previews in Github:

Runtime environment variables in your static site

Meli allows you to override any path in your site with dynamically generated content, per branch.

Let's see how this works with a basic Vue app. We'll replace our dist/index.html and upload it to our hello:

<!doctype html>
<html lang="en">
<head>
    <title>Meli example Vue.js app</title>
    <script src="https://cdn.jsdelivr.net/npm/vue@2/dist/vue.js"></script>
</head>
<body>

<div id="app">
    <div v-if="loading">Loading...</div>
    <div v-if="error">{{ error }}</div>
    <div v-if="env">
        <h2>{{ env.name }}</h2>
        <pre><code>{{JSON.stringify(env, null, 2)}}</code></pre>
    </div>
</div>

<script>
  const app = new Vue({
    el: '#app',
    data: {
      loading: true,
      error: undefined,
      env: undefined,
    },
    created: function () {
      this.loading = true;
      fetch('/env.json')
        .then(res => res.json())
        .then(env => this.env = env)
        .catch(err => this.error = err)
        .finally(() => this.loading = false);
    },
  });
</script>

</body>
</html>

Notice that we're fetching /env.json. We'll configure this file in Meli using the UI. For now, let's upload our site to our latest branch.

npx @getmeli/cli upload \
   ./dist \
    --url http://localhost:80 \
    --site "8f30f74f-4b63-4dc3-b8dc-788ca43740a8" \
    --token <site-token> \
    --branch "latest"

This branch will be available at https://hello.meli.domain.com. Now let's upload it to a new branch named demo:

npx @getmeli/cli upload \
   ./dist \
    --url http://localhost:80 \
    --site "8f30f74f-4b63-4dc3-b8dc-788ca43740a8" \
    --token <site-token> \
    --branch "demo"

This branch will be served at https://demo.hello.meli.domain.com.

Now, let's configure /env.json in Meli:

under branch latest, add a file redirect for path /env.json and with content {"name": "prod"}
in under branch demo, add a file redirect for path /env.json and with content {"name": "demo"}

Now, when you go to https://hello.meli.domain.com, you see this:

and https://demo.hello.meli.domain.com shows:

Wrap up

Meli is a really cool project which allows you to self-host your static sites and frontend apps. It features a lot of cool things, and more are to come.

Meli, a Netlify-like platform for deploying static sites

Geoffroy Empain — Fri, 11 Dec 2020 16:05:24 +0000

Hi there 👋

We used to host our sites on Netlify, but our eyes fill with glitter when we hear open source and self-hosted 🎉. So, we built Meli, which essentially is a Netlify alternative that lets you deploy static sites and frontend applications with ease, featuring per-branch deployments, web/slack/mattermost/email hooks, an API, and a way to manage organizations, teams and sites easily.

We built Meli on top of Caddy, a very powerful HTTP server. We've used Typescript, Node (backend), React (frontend) and MongoDB for the database.

It's a beta, but you can install super easily with Docker Compose: https://docs.meli.sh/get-started/installation

Check us out at https://github.com/getmeli/meli 🚀

Looking forward for your feedback 😀

I wrote this app to practice my React, Node, Mongo, Redis and Docker skills

Geoffroy Empain — Wed, 04 Nov 2020 11:39:07 +0000

Hi there 👋

Last week, as I was struggling to connect to my Gitlab.com account, I noticed that their status page was mentioning operational while in reality they were down - they later reported the incident.

That gave me the idea (spoiler alert, it's not something new) to create a very simple, painless website monitoring app where I could just add endpoints easily and get notified when something went down. Sure, I could use Prometheus and Grafana, but it's a hassle to manage when you've got several projects to monitor - and for most projects, I honestly don't look at CPU usage etc, I just want to know if they're up or down, so deploying the whole stack is unnecessary. Then you've got things like UpDown and Uptime Robot - and I'm certainly missing many others - but where's the fun when I have spare time and could practice my React, NodeJS, and MongoDB skills ?

I also wanted to experiment with Redis which I've heard so much about, configured in so many docker-compose.yml files but never actually used in code. I've also wanted to use Stripe's API and see how I could integrate billing in my apps for a while, so I figured this would be a good occasion - and I have to tell you, it is by far the most well designed, documented and sdk-complete API I have ever used (disclaimer, I don't work for Stripe, I just think it's important to recognize when something's truly great).

My requirements were quite simple:

simple way to add endpoints and customize request method and headers
simple way to configure notifications (email, Slack, Mattermost...)
a way to check my endpoints from different places in the world
fine tune the amount of down time before getting a notification
have a nice status page with cool - but meaningful - graphs

I also needed a cool name, so I went with "Probe" - I found the idea of having probes around the world a good match.

I published the app this week at https://probe.sh and would love to know what you think ! I was thinking about open sourcing it on Github as probe-sh/probe so anyone could self-host and help making it better - what do you think ? What license should I use ?

I've only deployed probes to France and Canada for now, but if you want other locations, additional notification types or features, let me know on Twitter @probe_sh or on Github 🚀. I'm already planning to add a public status page for endpoints and a way to group them - stay tuned !

Looking forward to your feedback 🎉

Looking for beta users !

Geoffroy Empain — Mon, 02 Nov 2020 10:55:17 +0000

Today we launched Pmbot 2.0.0 beta, and are looking for beta users that would like to try it out.

It's a complete re-write and setup is now just one click !

Blog article here.

New cloud platform at cloud.pmbot.io.

Looking forward to your feedback !

Visualizing your dedication to writing code

Geoffroy Empain — Sun, 01 Nov 2020 10:12:42 +0000

I'm a huge fan of visualizations and how you can get data to tell stories 📖.

Today I stumbled upon my activity diagram in Gitlab. It made me realize in a glimpse how little I knew the time I dedicate writing code 🧑‍🚀.

It's always interesting to look back, analyze and visualize data, to get a different angle from something you are involved with.

Gitlab, Github and Gitea offer similar visualizations, and I think Bitbucket provides slightly different graphs.

Do you know of any tool that helps understand your commitment to writing code by visualizing data in an authentic and meaningful manner ?

Share yours !

Happy coding 🚀

I'm also on Twitter @gempain 👍

How to CI your project like a champ in 2 minutes

Geoffroy Empain — Sun, 20 Sep 2020 14:39:27 +0000

Today I'll be showing you how to setup CI for your project in less than 2 minutes with Metroline, an open source, self hosted CI. I'll be using Gitea for this tutorial but you could use Gitlab or Github.

Install Metroline (1 minute)

Create a Gitea OAuth app and copy your Client ID and Client Secret

Copy this docker-compose.yml and:
- set METROLINE_GITEA_CLIENT_ID to your Gitea client ID
- set METROLINE_GITEA_CLIENT_SECRET to your Gitea client secret
- set METROLINE_GITEA_URL to the URL of your Gitea server
- change 192.168.43.36 with your IP
- set METROLINE_JWT_SECRET with a random secret obtained from openssl rand 32 -hex
- set METROLINE_RUNNER_SECRET with a random secret obtained from openssl rand 32 -hex

Now, run docker-compose up -d and browse to http://<your-ip>:3000. Click Sign in. You'll see the list of your repos. Click Setup on your favorite project, and you're all set !

Add CI config file and run first pipeline (30 seconds)

At the root of your project, add a .metroline.yml file with this content:

version: '1'
image: node:12-alpine
jobs:
  install:
    script:
      - npm ci
  test:
    script:
      - npm test
    dependencies:
      - install

Commit, push, and you Metroline starts building your commit immediately.

Pipeline statuses are reported to Gitea as they change. You'll be able to see it next to the commit, and clicking the commit status will open the pipeline in Metroline.

Conclusion

I've demonstrated the very basics here, but you can configure parallel jobs, secrets, conditionally execute jobs based on the branch or status of upstream jobs, you can also define pipeline environment, and more.

Also remember that this will work with Github and Gitlab, so I recommend you checkout the installation instructions for your favorite Git server.

Hope you find this useful !

Open Source CICD built with Docker, Node, React, MongoDB and TypeScript

Geoffroy Empain — Thu, 17 Sep 2020 12:26:35 +0000

😀 TL;DR

Our company is open sourcing Metroline, an in-house CI solution built with Docker, Node, React, MongoDB, Socket.io, D3 and TypeScript. It's self-hosted and works with Gitlab, Gitea and Github.

Project 👉 https://github.com/metroline/metroline
Demo 👉 https://demo.metroline.io
Installation 👉 https://docs.metroline.io/core/installation

🤔 TS;WM

We're a small team of 2 devs. We have been using Gitlab and Gitlab CI for over 3 years now. We have since looked for alternatives several times with no luck, until a few weeks ago. We initially tried Drone but it doesn't support Gitlab sub-groups which is blocking for us. Gitlab CI is a great tool, but we have had issues with the cache system where we sometimes had to artifact node_modules to get builds to work properly. In addition, it can be slow due to copying artifacts and preparing job workspaces.

A few months ago I started playing with Docker, Node and React to build a small CI proof of concept. The idea of making a CI myself was quite exciting and I felt driven by this feeling you get when everything comes to life. Surely was I even more excited when my proof of concept started actually working.

I wanted to write a CI that would run jobs inside Docker containers. This has become the standard for all CI platforms and has revolutionized how we build and ship code today. Big ups to Docker for changing our life for the better 👍.

📚 Choosing technologies

A lot of popular Open Source projects use Go, Ruby, sometimes Node, PHP, etc. I'm a Node and JS fan all the way (I've used Java for 5 years but I'm just way too productive with JS), so the question wasn't really difficult. Plus, I wanted to practice React and keep the backend a pure ExpressJS app. MongoDB is my favorite DB and the integration overhead in Node is almost non-existant using their official driver. I actually haven't used an ORM at all, and it's just so much easier when the number of layers between your API call and the actual DB is low - but that's another story.

I wanted things to be live, so I went with Socket.io, their API is well designed and it's not too hard to get it right the first time.

CIs out there have a lot of ways to display jobs/pipelines. I wanted to be able to model a workflow without constraints (such as using stages in Gitlab CI). To model this, I've played around with D3. I've obtained some pretty good results, but I would love if one of you D3 masters out there can help enhance the graph we have.

💻 Work, work, work

After a few evenings and weekends writing the bare bones, I had something working. I could trigger jobs and see live logs.

I showed this to my business partner and we decided that I would work on this full time to get something we could use to replace Gitlab CI inside our company. It's a good learning experience and there are great technical challenges.

So I got to the task. Cleaned up the backend and the UI, added environment management, logging, security, Docker images, parallel jobs, secrets, branch protections, and more. I quickly split the backend into two: server + runner. I haven't worked on multi-machine setup yet, because cross-machine workspace management is still being analyzed, but you can already have multiple runners on the same machine.

I initially used Gitea because it was easy to develop with, but I quickly added Gitlab and Github support and structured the code so that it would be easy to extend to other Git servers (PRs welcome !).

🚀 What's next

The UI, server and runner as well as docs are all published on Github:

At this stage, the platform has all the features that we use in Gitlab CI, but there are a bunch of things we'd like to add, and plenty of improvements we'd love to make. We've got features planned for pipeline approvals, multi-machine runners, build badges, and a lot more. PRs, issues, questions, all is welcome and will be greatly appreciated.

And, if you ever happen to feel bored, have spare time, have already watched all the pictures of kittens available on the World Wide Web, and if you're so desperate to find something to do, then join us in the extraordinary boredom of writing Jest tests.

In the name of our humble team of two, I sincerely hope you enjoyed this post and that we'll be hearing from you. Let us know on twitter @metrolineio !

Cheers 🍻

Are your Ruby gems up to date ?

Geoffroy Empain — Mon, 17 Aug 2020 16:13:35 +0000

Do you write Ruby applications ? Are your gems up to date ? You can now automatically update your Ruby gems with our CLI v1.10.0+ !

All you need to do is update your .pmbot.yml:

version: '1'
packageManagers:
  - packageManager:
      name: ruby

and use our latest pmbot/bot:ruby Docker image that embeds Ruby 2.7 and Bundler 2.1.4.

Go secure !

Read further:

PHP and Composer lovers, this if for you

Geoffroy Empain — Tue, 04 Aug 2020 17:14:59 +0000

We all know how it goes... our PHP Composer dependencies get out of date and we forget to update them, and that's not good if we want to keep shipping safe apps. I'd recommend using an automated dependency update bot: Pmbot.

All you need to do is to use our latest CLI v1.9.0 and use our composer plugin in your .pmbot.yml:

version: '1'
packageManagers:
  - packageManager:
      name: composer

If you haven't done it yet, install Pmbot with Docker in a couple of minutes: instructions here.

Ruby/Gem lovers, stay tuned !

Official website: https://pmbot.io
Blog: https://blog.pmbot.io
Docs: https://docs.pmbot.io

This Angular helper function has saved me from memory leaks for 4 years

Geoffroy Empain — Mon, 03 Aug 2020 17:30:34 +0000

I have been working with Angular for more than 4 years now. From Angular 2 to Angular 10, this helper function has followed me everywhere:

export function unsubscribe(subscription: Subscription | Subscription[]) {
  const subscriptions = Array.isArray(subscription) ? subscription : [subscription];
  subscriptions.forEach(s => {
    if (s && !s.closed) {
      s.unsubscribe();
    }
  });
}

and here's how to use it:

@Component({
  selector: 'my-component',
  template: `
    <div>
      {{counter}}
    </div>
  `
})
export class MyComponent implements OnInit, OnDestroy {

  private subscriptions = [];

  counter = 0;

  ngOnInit() {
    this.subscriptions.push(
      // memory leak ahead !
      timer(0, 1000)
        .subscribe(() => this.counter++),
    );
  }

  ngOnDestroy(): void {
    unsubscribe(this.subscriptions);
  }

}

Now, when your component is destroyed, you are safe from memory leaks as you have properly unsubscribed from the RxJS observable.

Gitea and Drone CI lovers, this is for you

Geoffroy Empain — Mon, 03 Aug 2020 17:05:21 +0000

You love Gitea and we do too ! This weekend, we've added Gitea support to Pmbot. You will now be able to do automated dependency updates of your Gitea projects using DroneCI.

We've written a blog post for you to get started ! Check it out at https://blog.pmbot.io/announcing-support-for-gitea/

Our your deps up to date ?

The magic behind IDE autocompletion for files like angular.json

Geoffroy Empain — Mon, 03 Aug 2020 12:49:27 +0000

We all use frameworks like Angular, React and tools like ESLint, Npm, etc.

Have you ever wondered how your IDE gives you autocompletion for files like angular.json, package.json, .eslintrc, and many more ?

Well, they match your files against several remote JSON Schema stores, among which the most popular is schemastore.org.

Their API provides a catalog of JSON Schemas that describe various commonly used files.

There are two types of entries:

static: references a file stored directly on schemastore.org
dynamic: references a URL which points to a specific JSON Schema

The advantage of dynamic entries is that you can update your JSON Schema without having to update your entry in the catalog, and that's exactly what .angular-cli.json does:

{
  "name": ".angular-cli.json",
  "description": "Angular CLI configuration file",
  "fileMatch": [".angular-cli.json", "angular-cli.json"],
  "url": "https://raw.githubusercontent.com/angular/angular-cli/master/packages/angular/cli/lib/config/schema.json"
}

At Pmbot, we automatically generate and publish the JSON Schema of our CLI configuration file to our Github config repo every time we release a new version of our CLI. The entry for our .pmbot.yml in the schemastore.org points to the raw JSON Schema file hosted on Github.

Thanks for reading !