DEV Community: Valentin Prugnaud 🦊

AI Content Creation: a Challenge or Opportunity for Publishing Platforms?

Valentin Prugnaud 🦊 — Fri, 09 Jun 2023 18:00:00 +0000

As AI is gaining in traction and democratizes content creation, it presents both challenges and opportunities for publishing platforms. Shall they fight it or embrace it?

In the age of digital revolution, artificial intelligence (AI) has been pivotal, altering the landscape of many sectors, including content creation. As AI technology, particularly large language models, becomes more accessible to everyday users, we are witnessing an unprecedented democratization of content creation. However, this paradigm shift raises pertinent questions: Should publishing platforms take notice, and if so, should they resist or embrace this change?

There are a few reason why AI could actually benefit publishing platforms and assist a lot of folks to share their ideas more effectively.

Human-AI Collaboration

Historically, busy individuals and companies have often employed ghostwriters to produce content. Now, in the AI era, these ghostwriters are increasingly being replaced by algorithms. The time-saving potential of AI is significant. It's like having a personal writing assistant who never tires, always available at your beck and call.

Now, this isn’t necessarily a bad thing. A lot of folks would love to share their ideas, but simply don’t have the time or get struck with writer’s block. Using ChatGPT or similar to help you organize your thoughts and guide you in the outline process, even generate some basic paragraphs to help you get started is a good thing.

AI doesn't generate content from nothingness. Large language models require human prompts to guide their outputs. Humans are still very much in the driver's seat, providing the creative direction and oversight.

AI as a Language Equalizer

AI in content creation also holds promise as a language equalizer. Non-native English speakers can greatly benefit from AI models that help redact their ideas into coherent, well-written articles.

However, some platforms are imposing a mandatory disclosure of AI assistance. This could inadvertently discriminate against these individuals. Readers will see the “AI-assisted” tag or footnote and automatically disregard the article, even if AI played only a small part in it.

The debate over AI-assistance disclosure is a complex one and far from settled, but we should keep in mind that a lot of folks are using AI-assistance to write content in good faith and should not be penalized for it.

The Role of Publishing Platforms in the AI era

Publishing platforms face a crossroads: to resist or embrace AI-written or AI-assisted content. Different platforms may choose different strategies, depending on their goals and audiences.

However, considering the advantages of AI in content creation, it may be wise to adapt and integrate AI-assisted writing rather than fighting it. Publishing platforms are also, in most cases, promoting and facilitating freedom of expression. That should include the right to express your opinions and ideas, whichever way you choose, AI-assisted or not.

The rise of AI in content creation presents both challenges and opportunities. As AI technology continues to evolve, so too will its role in content generation and our discussions around it. Perhaps the most vital thing, whether we are readers, writers, or publishers, is to stay engaged in this conversation, ready to adapt and evolve with the changing landscape of AI and writing.

Originally published on: https://whatdafox.substack.com/

Navigating Developer-Led Projects: Characteristics, Benefits, and Challenges

Valentin Prugnaud 🦊 — Mon, 05 Jun 2023 07:00:00 +0000

Today's business landscape is marked by constant change and innovation, driven by a fast-paced digital environment that demands agility, adaptability, and creativity. In this context, traditional project management models may no longer be sufficient to keep up with the pace of technological advancements and the evolving needs of customers and end-users.

Enter developer-led projects, a new approach to project management that empowers developers to take ownership of projects and drive innovation from the front lines.

In this article, we will explore the characteristics, benefits, and challenges of developer-led projects and provide practical tips for navigating this exciting new terrain.

What are developer-led projects?

Developer-led projects are a new approach to project management that puts developers in charge of the project's direction and execution. In this model, developers are given a high degree of autonomy and responsibility to lead the project from start to finish.

Developer-led projects can bring a strong sense of ownership and accountability for developers. In this model, developers are not simply responsible for writing code, but they are also expected to take an active role in defining project goals, making strategic decisions, and ensuring that the project is successful. This sense of ownership can lead to a higher level of motivation and engagement among developers, as they feel empowered to take ownership of their work and see the impact of their contributions.

What are the benefits?

Developer-led projects offer a number of benefits over traditional, top-down project management models. Here are a few of the key benefits of developer-led projects:

Improved collaboration and teamwork: In developer-led projects, developers are empowered to take ownership of the project and work closely with other stakeholders to achieve project goals. This fosters a culture of collaboration and teamwork, as developers are encouraged to share ideas, ask questions, and work together to solve problems.
Greater innovation and creativity: By giving developers a high degree of autonomy and responsibility, developer-led projects can foster a culture of innovation and creativity. Developers are encouraged to experiment, take risks, and try out new ideas, which can lead to breakthroughs and new approaches to problem-solving.
Increased agility and flexibility: Developer-led projects are often associated with agile methodologies, which prioritize flexibility and adaptability. This means that developers can make decisions on the fly, iterate quickly based on feedback, and adjust the project's direction as needed to ensure that it meets customer needs and strategic goals.
Improved quality: By putting developers in charge of the project, organizations can tap into their technical expertise and attention to detail to ensure that the project meets high quality standards. Developers are often better positioned than other stakeholders to identify potential technical issues and ensure that the code is clean, efficient, and well-documented.
Higher level of developer engagement: When developers are given a high degree of autonomy and responsibility, they are more likely to feel engaged and motivated in their work. This can lead to higher levels of job satisfaction, reduced turnover, and improved overall performance.

Overall, developer-led projects represent a new approach to project management that can offer a range of benefits over traditional top-down models. By empowering developers to take ownership of the project and work closely with other stakeholders, organizations can tap into their creativity, problem-solving skills, and technical expertise to drive innovation and improve the quality of the final product.

What about the challenges?

While developer-led projects offer a number of benefits, they can also present some unique challenges. Here are a few of the key challenges that organizations may face when implementing a developer-led approach:

Lack of project management expertise: Developers may not have the same level of experience or expertise in project management as traditional project managers, which can lead to difficulties in areas such as planning, scheduling, and resource allocation.
Lack of alignment with business objectives: In some cases, developers may be more focused on technical excellence than on meeting business objectives or customer needs. This can lead to a misalignment between the project goals and the overall strategic direction of the organization.
Potential for scope creep: Developer-led projects can be more flexible and agile than traditional top-down approaches, but this can also lead to scope creep if developers are not careful. Without clear direction and guidance, developers may be tempted to add features or functionality that are not essential to the project's success, leading to delays, cost overruns, and other issues.
Difficulty in managing stakeholder expectations: In developer-led projects, developers are often the primary point of contact for stakeholders such as business leaders, customers, and end-users. This can lead to difficulties in managing stakeholder expectations and ensuring that the project meets the needs of all parties involved.
Challenges in team dynamics: Developer-led projects can be highly collaborative and team-oriented, but they can also present challenges in team dynamics if developers are not used to working closely with other stakeholders or developers from other teams. It is important to establish clear communication channels, roles and responsibilities, and decision-making processes to ensure that everyone is working together effectively.

Overall, while developer-led projects can offer many benefits, they require careful planning and management to ensure that they are successful. In the next section, we’ll go over a few strategies for overcoming these challenges.

How to overcome/mitigate them?

Developer-led projects aren’t a silver bullet and always a replacement for traditional project-management approaches. However, many challenges can be avoided with a few strategies:

Ensure that everyone on the team understands the project goals and how they align with the overall strategic direction of the organization.
Clearly define the project scope, timeline, and deliverables, to avoid scope creep and ensure that everyone is working towards the same goals.
Establish clear communication channels and protocols, to ensure that everyone is kept informed and up-to-date on project progress and issues.
Hold regular team meetings and status updates, to ensure that everyone is aligned and working towards the same goals.
Establish a process for identifying and mitigating risks, and ensure that everyone on the team is aware of their roles and responsibilities in managing risks.
Encourage open communication about potential issues and challenges, and work collaboratively to address them as soon as they arise.
Regularly review project processes and practices, and look for ways to optimize and streamline them.
Document every decision and encourage every developer to do so.

When should you consider developer-led projects?

Developer-led projects can be a good fit in many situations, but there are some scenarios where they are particularly effective. Here are a few situations where a developer-led approach may be the right choice:

When the project is highly technical

For highly technical projects, a developer-led approach can be particularly effective because developers are often best equipped to understand and solve complex technical problems.

Examples

Adopting a new architecture for applications
Breaking down a monolithic application to microservices
Implementing infrastructure changes
Moving to another cloud provider
Migrating to new CI/CD tooling
etc.

When there is a need for innovation

Innovation is often driven by experimentation and creativity, which are qualities that many developers possess. By putting developers in charge of a project, organizations can encourage a culture of innovation and experimentation, which can lead to new and innovative solutions.

Examples

Experimenting with new technologies (AI, Blockchain, etc.)
Exploring a new product idea
Attempting to reduce toil
etc.

When speed is critical

When speed is critical, a developer-led project can be an effective way to accelerate the project timeline. Developers are often able to work more quickly and efficiently than traditional project managers, and they are better equipped to handle the technical challenges that may arise during the project. In addition, a developer-led approach can be more agile and flexible, allowing developers to adapt to changing requirements or unexpected challenges more quickly.

Examples

Paying tech-debt
Refactoring an application
Reducing dependencies
Improving performance
etc.

When collaboration is important

Collaboration is a key factor in the success of many projects, and a developer-led approach can be particularly effective for fostering collaboration and teamwork. When an initiative impacts the work of multiple teams, it might be worth creating a dedicated “task-force” to iterate on the ideal solution.

Examples

Choosing and implementing a feature flagging solution
Choosing and implementing an analytics pipeline
Choosing and implementing observability tooling
etc.

Conclusion

Ultimately, the success of any project depends on a range of factors, including the project team's skills and expertise, the project's goals and objectives, and the organization's culture and values. But by embracing a developer-led approach for some projects, organizations can tap into the power of technology and innovation to drive growth, innovation, and success.

Navigating Developer-Led Projects: Characteristics, Benefits, and Challenges

Developer-led projects are a new approach to project management that empowers developers to take ownership of projects and drive innovation.

whatdafox.substack.com

The Importance of Developer Experience

Valentin Prugnaud 🦊 — Sat, 03 Jun 2023 20:50:35 +0000

Developer Experience, or DX, is a critical aspect of software development in the modern enterprise. It encompasses the tools, processes, and environment that developers use to build, test, and deploy software. In recent years, there has been growing recognition of the importance of DX and its impact on developer productivity and mental health. In this article, we'll explore why DX matters and what enterprises can do to improve the experience of their developers.

Why Developer Experience Matters

The development experience has a direct impact on the quality of the software produced and the productivity of the developers themselves. Poor DX can lead to increased frustration, decreased motivation, and lower productivity among developers. On the other hand, a positive DX can lead to higher job satisfaction, increased motivation, and improved productivity.

One of the key benefits of improving developer experience is that it helps to reduce the stress and burnout that can come from working in a fast-paced, complex environment. When developers are given the tools and processes they need to get their work done efficiently, they are more likely to feel in control and less stressed. Additionally, a positive development environment can help to build trust and foster collaboration among team members, which can lead to more effective problem-solving and faster resolution of technical issues.

Another important benefit of improving DX is increased productivity. Developers who are able to work more efficiently are able to focus on high-value tasks and get more done in less time. This, in turn, can help to improve the speed of software delivery and reduce the time-to-market for new features and products. Additionally, by improving the development process and reducing the time and effort required to complete tasks, enterprises can help to reduce the risk of burnout among their developers and increase the long-term sustainability of their development teams.

Improving Developer Experience

So, how can enterprises improve the developer experience for their teams? There are a number of key steps that they can take, including:

Invest in the right tools and technologies. This includes not just software development tools, but also other technologies that can help to streamline the development process, such as project management and collaboration tools, version control systems, and testing and deployment tools.

Foster a positive work environment. This includes creating an inclusive and supportive work environment that values diversity and fosters collaboration. It also includes providing developers with the resources and support they need to be successful, such as mentorship and training programs, flexible work arrangements, and access to mental health resources.

Encourage a culture of continuous improvement. This includes encouraging developers to share their feedback and ideas for improvement, and to participate in hackathons, code sprints, and other collaborative initiatives that can help to improve the development process.

Provide clear communication and expectations. This includes establishing clear expectations for development work, such as timelines, deliverables, and project goals, as well as providing regular feedback and recognition to developers.

Conclusion

In conclusion, the development experience is a critical aspect of software development that has a significant impact on both developer productivity and mental health. By investing in the right tools and technologies, fostering a positive work environment, encouraging a culture of continuous improvement, and providing clear communication and expectations, enterprises can improve the experience of their developers and achieve better outcomes for their development teams and their businesses as a whole.

WhatDaFox | Valentin Prugnaud | Substack

Thoughts on technology, developer experience, mental health, and more... Click to read WhatDaFox, by Valentin Prugnaud, a Substack publication. Launched 8 months ago.

whatdafox.substack.com

Custom v-model with Vue.js: Update

Valentin Prugnaud 🦊 — Thu, 11 Aug 2022 20:25:00 +0000

A while back, in 2019, I wrote an article demonstrating how to create a custom Vue component, and handle the v-model capabilities:

https://dev.to/valentinprgnd/wrap-a-text-field-in-a-component-with-vue-js-gak

I recently discovered an alternative way to do it, which does not require a watcher, thus making the code much faster and less resource heavy.

The original post suggested this method:

<template>
  <div class="custom-input">
    <input v-model="localValue" placeholder="Enter your name">
  </div>
</template>

<script>
export default {
  name: "TextField",
  props: {
    value: String // 1. Receives the value as a prop
  },
  data() {
    return {
      localValue: ""
    };
  },
  created() {
    this.localValue = this.value; // 2. Copy the value in a local value variable

    // Set a watcher to emit the changes to the parent component
    this.$watch("localValue", value => {
      this.$emit("input", value);
    });
  }
};
</script>

While functional, the use of a watcher here can be really resource heavy (particularly if you create a lot of such components).

A better approach would be to use a computed property, like so:

<template>
  <div class="custom-input">
    <input v-model="localValue" placeholder="Enter your name">
  </div>
</template>

<script>
export default {
  name: "TextField",
  props: {
    value: String // 1. Receives the value as a prop
  },
  computed: {
    localValue: {
      get() {
        return this.value;
      },
      set(value) {
        this.$emit('input', value);
      }
  }
};
</script>

Not only it reduces the boilerplate code, but it also avoids the use of a watcher, making your component faster and less resource heavy 🎉

Moderate posts automatically with the Perspective API

Valentin Prugnaud 🦊 — Fri, 10 Apr 2020 00:00:00 +0000

We all know the Internet we know and love isn't always a safe place, but there are innovations that we can easily
leverage to make it a better place.

Recently, amid this whole COVID–19 situation, my co-founders and I decided to create a platform, for Canadians to thank
all the workers working on the front lines, risking their lives, for us while we stay at home: Together North. The whole country and many other places in the world started clapping and cheering at a dedicated time every day to show their gratitude.
But we thought it would be a good idea to have a dedicated place where people could leave their gratitude messages, share it directly with
the people they are cheering for and keep it online as a reminder.

And it was a good idea. The only problem was: some people don't go on the Internet to share love and compassion, but to write mean comments
and spread hate instead. And Together North was a perfect target: we are a small team and it is an open text message. There is room for abuse and we can't monitor every message manually.

Here comes the Perspective API. I decided to use this API to evaluate every incoming message
and decide whether or not that message should be published, or if it should be flagged and evaluated by a human.

Let's dive into how it works.

Concept

The concept is simple: create a Firebase Function to evaluate any incoming message upon creation, run it through the Perspective API and based on the "Toxicity" result, decide whether or not we should display it or not.

After running a few manual tests with carefully chosen words, I decided to use a threshold of 25% toxicity. Anything above 25% would be flagged as "toxic", unpublished and forwarded to us in a dedicated Slack channel for human evaluation. Anything below 25% would automatically be approved, published on the platform but also forwarded into our Slack channel for good measure and proofreading just in case.

Setup

We already have a "messages" collection on Firestore where we store all of our incoming messages. To decide whether or not we should display the message, we updated every document with a "published" flag. If true, it is displayed on the platform, if not, it is hidden until further notice.

Then, we created the Firebase Function with the code to evaluate the message and send the alerts. This function is triggered every time a message is created in the collection on Firestore.

Let's take a look at the code, shall we?

Code

Here is the code we used for the Firebase Function:

const functions = require('firebase-functions');
const admin = require('firebase-admin');
const Perspective = require('perspective-api-client');
const get = require('get-value');
const { WebClient } = require('@slack/web-api');

// Initialize
const slack = new WebClient(functions.config().slack.token);
const perspective = new Perspective({ apiKey: functions.config().perspective.api_key });

admin.initializeApp();

exports.moderateMessages = functions.firestore.document('messages/{message}').onCreate(async (snapshot, context) => {
    const id = snapshot.id;
    const data = snapshot.data();

    // Evaluate toxicity of the message via the Perspective API
    const result = await perspective.analyze(data.message);

    const toxicity = get(result, 'attributeScores.TOXICITY.summaryScore.value', {
        default: 1
    });

    if (toxicity * 100 < 25) {
        // Message is safe, approve it
        await slack.chat.postMessage({
            text: `@channel A safe message has been published on Together North! https://togethernorth.ca/m/${id}`,
            blocks: [{
                'type': 'section',
                'text': {
                    'text': `@channel A safe message has been published on Together North! https://togethernorth.ca/m/${id}`,
                    'type': 'mrkdwn'
                },
                'fields': [
                    {
                        'type': 'mrkdwn',
                        'text': `*ID*: ${id}`
                    },
                    {
                        'type': 'mrkdwn',
                        'text': ' '
                    },
                    {
                        'type': 'mrkdwn',
                        'text': `*Message*:\n${data.message}`
                    }
                ]
            }],
            channel: '#together-north',
        });
        return admin.firestore().collection('messages').doc(id).update({
            result,
            moderationScore: toxicity,
            published: true
        });
    } 

    // Message is not safe, send a message to Slack
    await slack.chat.postMessage({
        text: `@channel A suspicious message has been blocked on Together North!`,
        blocks: [{
            'type': 'section',
            'text': {
                'text': '@channel A suspicious message has been blocked on Together North!',
                'type': 'mrkdwn'
            },
            'fields': [
                {
                    'type': 'mrkdwn',
                    'text': `*ID*: ${id}`
                },
                {
                    'type': 'mrkdwn',
                    'text': ' '
                },
                {
                    'type': 'mrkdwn',
                    'text': `*Message*:\n${data.message}`
                }
            ]
        }],
        channel: '#together-north',
    });
    return admin.firestore().collection('messages').doc(id).update({
        result,
        moderationScore: toxicity,
        published: false,
    });
});

The logic is fairly simple: when a message is created, run the message through the Perspective API, if the toxicity level
is below 25%, share it in our Slack channel with the URL for easy reference and mark it as published. We store the toxicity
report from the API as well out of curiosity.

However, if the message has a toxicity level higher than 25%, then we send a different Slack notification to our Slack channel,
mark the document as unpublished and store the toxicity report as well for easy review by our team.

If you are curious about using Firebase, the Perspective API or the Slack API, get in touch with me on Twitter or in the comments.

PS: If you live in Canada or just want to share the love, leave a message on Together North!

Unit Testing with Nuxt.js

Valentin Prugnaud 🦊 — Fri, 06 Mar 2020 08:21:01 +0000

I’m currently working on an app built with Nuxt.js. I have written a couple tests, but they only test component mounting and its template against a snapshot, but it doesn’t test much and it doesn’t seem scalable.

I’m more of a backend dev initially, so I am not familiar with the best practices to write unit tests with Nuxt/Vue.js.

Any tips or best practices to run unit tests with Nuxt/Vue at scale? What is your experience with it?

Productivity Pixel - Automate everything

Valentin Prugnaud 🦊 — Fri, 28 Feb 2020 22:28:18 +0000

1 - CI/CD tools

GitLab CI, GitHub Actions, Travis CI, Circle CI… you name it! Take advantage of these amazing tools to automate your workflow.

2 - Command Line

Often overlooked, the command line is also an amazing tool. You can write small apps or scripts to automate part of your workflow or even the whole thing!

3 - Slack

“ChatOps” are all the rage these days, and for a good reason: it’s convenient and easy to share with your team.

4 - Pub/Sub & Cloud Functions

This combo requires a bit more work, but leveraging a Pub/Sub topic with a few Cloud Functions can do wonders!

You can also find these pixels on my Instagram: https://instagram.com/valentinprgnd. I will publish Pixels every Monday, Wednesday, and Friday about career development in tech, code, mental health and health for developers. Follow me for more tips @valentinprngd and check out my podcast https://rebased.whatdafox.com.

Code Pixel - Write better documentation

Valentin Prugnaud 🦊 — Thu, 27 Feb 2020 00:39:35 +0000

1 - Stay simple

We all want to add every single detail in our documentation. But sometimes, less is more. Get straight to the point.

2 - Avoid patronizing vocabulary

“It’s super easy”… Yet, if your users are struggling to follow the steps in your documentation, that can make them feel bad and give up. Avoid patronizing language in your documentation as much as you can.

3 - Make it searchable

If your documentation is a standalone site, make it searchable. Tools like Algolia allow you to implement a search engine on your site with a few steps.

4 - Be polyglot

If you can, display the code snippets in multiple languages, relevant to your users.

Career Pixel - Be a better programmer

Valentin Prugnaud 🦊 — Tue, 25 Feb 2020 08:25:47 +0000

1 - Be nice

Be nice to your co-workers, clients, you name it. Listen closely and help them whenever you can.

2 - Be empathetic

To me, empathy is the most important skill a programmer should have. Make a conscious effort to understand your co-workers' point of view, your users' point of view. Try your best to understand where they are coming from.

3 - Be organized

Keep track of your tasks. find your rhythm and habits, and be consistent. Document EVERYTHING.

4 - Be a mentor

Here’s one thing I believe in: you never truly know something until you can successfully teach it. Mentor or help others with their projects or even a simple task. Not only it’s a nice thing to do, but it will also improve your skills in the process.

Deploy Vue.js on Google Cloud Run

Valentin Prugnaud 🦊 — Tue, 25 Feb 2020 00:00:00 +0000

Repository: WhatDaFox/vuejs-cloud-run-poc

Configure Google Cloud

To be able to build and deploy, you will need a Google Cloud project, with a billing account set up, as well as
the Google Cloud CLI installed.

Then you will need to create a configuration for your project:

$ gcloud config configurations create cloud-run
$ gcloud auth login # and follow the steps
$ gcloud config set project YOUR_PROJECT_ID

Create the project

$ npm i -g @vue/cli
$ vue create cloud-run

Vue CLI creates a Single Page Application type of project, so I needed to install serve to serve the project after the build.

To install serve, run:

$ npm install --save-dev serve

I had to update the package.json file with the "start" script, like so:

"scripts": {
    ...,
    "start": "serve -p $PORT dist/",
}

Now we are ready to create the Dockerfile.

Create the Dockerfile

Now we can build the app and run the start command.

# Use the official lightweight Node.js 12 image.
# https://hub.docker.com/_/node
FROM node:12-alpine

ENV PORT=8080

# Create and change to the app directory.
WORKDIR /usr/src/app

RUN set -ex && \
    adduser node root && \
    chmod g+w /app && \
    apk add --update --no-cache \
      g++ make python \
      openjdk8-jre

# Copy application dependency manifests to the container image.
# A wildcard is used to ensure both package.json AND package-lock.json are copied.
# Copying this separately prevents re-running npm install on every code change.
COPY package*.json ./

# Install production dependencies.
RUN npm ci

# Copy local code to the container image.
COPY . ./

RUN npm run build

# Run the web service on container startup.
CMD [ "npm", "run", "start" ]

Build & Deploy

Now, we can use Cloud Build to build our docker image. Cloud Build will automatically detect our Dockerfile, build,
and push our image in Google Container Registry:

$ gcloud builds submit --tag gcr.io/YOUR_PROJECT/helloworld

Once that's done, we can run the following command to deploy our new revision to Cloud Run:

$ gcloud run deploy --image gcr.io/YOUR_PROJECT/helloworld --platform managed

Benchmark

When testing, I ran a small (to avoid crazy costs) benchmark with Apache Benchmark.

Here is the command I ran:

$ ab -n 1000 -c 80 https://cloud-run-url/

Here are the results:

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking helloworld-2fjcn3qpbq-uw.a.run.app (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Google
Server Hostname:        helloworld-2fjcn3qpbq-uw.a.run.app
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        helloworld-2fjcn3qpbq-uw.a.run.app

Document Path:          /
Document Length:        746 bytes

Concurrency Level:      80
Time taken for tests:   8.671 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      1272004 bytes
HTML transferred:       746000 bytes
Requests per second:    115.33 [#/sec] (mean)
Time per request:       693.656 [ms] (mean)
Time per request:       8.671 [ms] (mean, across all concurrent requests)
Transfer rate:          143.26 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       49  391 156.9    370     888
Processing:    32  252 106.9    285     878
Waiting:       28  198 101.0    185     876
Total:        313  643 204.8    620    1398

Percentage of the requests served within a certain time (ms)
  50%    620
  66%    703
  75%    734
  80%    790
  90%    898
  95%   1054
  98%   1136
  99%   1194
 100%   1398 (longest request)

Conclusion

Really easy to deploy VueJS on Cloud Run and the performances aren't bad, even with a cold start.

Deploy NestJS with Fastify on Google Cloud Run

Valentin Prugnaud 🦊 — Thu, 20 Feb 2020 00:00:00 +0000

Repository: WhatDaFox/nestjs-fastify-cloud-run-poc

Configure Google Cloud

To be able to build and deploy, you will need a Google Cloud project, with a billing account set up, as well as
the Google Cloud CLI installed.

Then you will need to create a configuration for your project:

$ gcloud config configurations create cloud-run
$ gcloud auth login # and follow the steps
$ gcloud config set project YOUR_PROJECT_ID

Create the project

For this proof of concept, I will only use the default NestJS application, that contains a single endpoint /
returning Hello world!:

$ npm i -g @nestjs/cli
$ nest new cloud-run

Install the Fastify driver:

$ npm i --save @nestjs/platform-fastify

We need to update main.ts to make use of the Fastify driver. Also, Cloud Run will decide the port of our application, so we have to update the main.ts file to reference
the PORT environment variable, like so:

import { NestFactory } from '@nestjs/core';
import { FastifyAdapter, NestFastifyApplication } from '@nestjs/platform-fastify';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create<NestFastifyApplication>(
    AppModule,
    new FastifyAdapter({ logger: true }),
  );
  app.enableCors();
  await app.listen(parseInt(process.env.PORT) || 3000, '0.0.0.0');
}

bootstrap();

Now we are ready to create the Dockerfile.

Create the Dockerfile

We need to containerize our application to be able to run on Cloud Run. Create a Dockerfile at the root of your project
and copy/paste the following:

For better performance, I decided to build the app before hand and run the start:prod command.

# Use the official lightweight Node.js 12 image.
# https://hub.docker.com/_/node
FROM node:12-alpine

# Create and change to the app directory.
WORKDIR /usr/src/app

# Copy application dependency manifests to the container image.
# A wildcard is used to ensure both package.json AND package-lock.json are copied.
# Copying this separately prevents re-running npm install on every code change.
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy local code to the container image.
COPY . ./

# Build the application
RUN npm run build

# Run the web service on container startup.
CMD [ "npm", "run", "start:prod" ]

Build & Deploy

Now, we can use Cloud Build to build our docker image. Cloud Build will automatically detect our Dockerfile, build,
and push our image in Google Container Registry:

$ gcloud builds submit --tag gcr.io/YOUR_PROJECT/helloworld

Once that's done, we can run the following command to deploy our new revision to Cloud Run:

$ gcloud run deploy --image gcr.io/YOUR_PROJECT/helloworld --platform managed

Benchmark

When testing, I ran a small (to avoid crazy costs) benchmark with Apache Benchmark.

Here is the command I ran:

$ ab -n 1000 -c 80 https://cloud-run-url/

Here are the results:

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking cloud-run-url (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Google
Server Hostname:        cloud-run-url
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        cloud-run-url

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      80
Time taken for tests:   9.300 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      437004 bytes
HTML transferred:       12000 bytes
Requests per second:    107.53 [#/sec] (mean)
Time per request:       743.985 [ms] (mean)
Time per request:       9.300 [ms] (mean, across all concurrent requests)
Transfer rate:          45.89 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       79  461 213.7    430    2633
Processing:    37  208 118.9    200     506
Waiting:       22  163 105.3    139     501
Total:        129  669 220.7    626    2739

Percentage of the requests served within a certain time (ms)
  50%    626
  66%    702
  75%    768
  80%    772
  90%    862
  95%   1161
  98%   1371
  99%   1576
 100%   2739 (longest request)

Conclusion

Compared to my previous experiment with the default installation of NestJS, I didn't observe any improvement in response time.

Deploy NestJS on Google Cloud Run

Valentin Prugnaud 🦊 — Tue, 18 Feb 2020 00:00:00 +0000

Repository: WhatDaFox/nestjs-cloud-run-poc

Configure Google Cloud

To be able to build and deploy, you will need a Google Cloud project, with a billing account set up, as well as
the Google Cloud CLI installed.

Then you will need to create a configuration for your project:

$ gcloud config configurations create cloud-run
$ gcloud auth login # and follow the steps
$ gcloud config set project YOUR_PROJECT_ID

Create the project

For this proof of concept, I will only use the default NestJS application, that contains a single endpoint / returning Hello world!:

$ npm i -g @nestjs/cli
$ nest new cloud-run

Cloud Run will decide the port of our application, so we have to update the main.ts file to reference the PORT environment variable, like so:

import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.enableCors();
  await app.listen(process.env.PORT || 3000);
}
bootstrap();

Now we are ready to create the Dockerfile.

Create the Dockerfile

We need to containerize our application to be able to run on Cloud Run. Create a Dockerfile at the root of your project and copy/paste the following:

For better performance, I decided to build the app beforehand and run the start:prod command.

# Use the official lightweight Node.js 12 image.
# https://hub.docker.com/_/node
FROM node:12-alpine

# Create and change to the app directory.
WORKDIR /usr/src/app

# Copy application dependency manifests in the container image.
# A wildcard is used to ensure both package.json AND package-lock.json are copied.
# Copying this separately prevents re-running npm install on every code change.
COPY package*.json ./

# Install dependencies
RUN npm install

# Copy local code to the container image.
COPY . ./

# Build the application
RUN npm run build

# Run the web service on container startup.
CMD [ "npm", "run", "start:prod" ]

Build & Deploy

Now, we can use Cloud Build to build our docker image. Cloud Build will automatically detect our Dockerfile, build,
and push our image in Google Container Registry:

$ gcloud builds submit --tag gcr.io/YOUR_PROJECT/helloworld

Once that's done, we can run the following command to deploy our new revision to Cloud Run:

$ gcloud run deploy --image gcr.io/YOUR_PROJECT/helloworld --platform managed

Benchmark

When testing, I ran a small (to avoid crazy costs) benchmark with Apache Benchmark.

Here is the command I ran:

$ ab -n 1000 -c 80 https://cloud-run-url/

Here are the results:

This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking cloud-run-url (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Google
Server Hostname:        cloud-run-url
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-CHACHA20-POLY1305,2048,256
Server Temp Key:        ECDH X25519 253 bits
TLS Server Name:        cloud-run-url

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      80
Time taken for tests:   8.624 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      486004 bytes
HTML transferred:       12000 bytes
Requests per second:    115.95 [#/sec] (mean)
Time per request:       689.939 [ms] (mean)
Time per request:       8.624 [ms] (mean, across all concurrent requests)
Transfer rate:          55.03 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       61  402 219.1    375    2652
Processing:    29  207 117.5    192    1328
Waiting:       24  168 114.6    146    1279
Total:        163  609 236.4    567    2819

Percentage of the requests served within a certain time (ms)
  50%    567
  66%    622
  75%    681
  80%    714
  90%    804
  95%    920
  98%   1221
  99%   1754
 100%   2819 (longest request)

Conclusion

It is pretty straightforward to build and deploy a container to Cloud Run. The response time can sometimes be pretty slow,
but overall, if the container is small and quick to start, it should run pretty smoothly.