DEV Community: Fernando Alvarez

Hype Driven Development — How teams can avoid this

Fernando Alvarez — Tue, 27 Aug 2019 12:26:44 +0000

Hype Driven Development — How teams can avoid this

Introduction

Let’s imagine for a bit that you are in a development team doing software products or services, you have a very rock-solid planned platform, the team is doing well with the tools provided for your product specs, everything seems to be fine with the world.

One day, surfing the net, you notice that a new tool is released and is well received by the open source / framework community and, dare I say, is praised by everyone. Amazed by this, you read the documentation to learn how to use it, you tested it and, by the end of the day, you fall in love with this. Since your love for this new shiny tool is quite strong, you search a way or another to implement it in your project. You talk with your managers and leads about this and you convince them to use it. At the end of the month, the tool is implemented in your product and for now everything seems to be working.

Some time later, the team started to add more features on top of the tool that you suggested but you noticed a struggle in your team to have the features implemented, more bugs than before, taking more time to develop a feature, lots of “hacks” to get things done with the tool and etc. After some chitchat with your team and the leads, you come to the conclusion that adding this tool was not the best decision since it started to hurt the development cycle and, somehow, started to hurt the business. You and the team remove this tool and you have a lesson learned.

After reading this story… does it feel quite familiar to you? This topic is something what I like to call Hype Driven Development.

What is Hype Driven Development (HDD)?

I like to call it like this when you try to push a new tool / framework and then make decisions in your development team of including it without thinking of tradeoffs, technical debt, development and business implications.

Why is it harmful in development teams?

If you read the introduction, you may noticed a couple of problems that HDD can introduce to your teams but I want to be more explicit on this.

One of the problems that HDD causes in your team is a decrease in the speed of your development teams. The reason behind this is that your team needs time to understand the new introduced tool and how to use it in the project and that learning curve can cause some delays when delivering a new feature (sometimes this may no apply) but on top of that, when the tool it’s fully implemented in the product, it may take time for all the devs how to build a feature on top of this and if it was a bad decision, your team will struggle more on that.

A bad decision cause by HDD can cause you more problems that solutions. Instead of going smoothly you may have more bugs introduced in your system and more delicate parts that will require your attention.

A bad decision caused by HDD can cause a waste of time. Sounds harsh but it’s the truth. If a decision wasn’t made in a smart way, you will waste time implementing it, maintaining it but also removing it.

How can I avoid this in my team?

In the company I work, I’m leading a team where we are building an internal product / platform and we faced this kind of behaviour in the team. I’ll tell you a couple of techniques that helped me to understand better the hype from the devs and probably avoid it (or fell for it).

Ask for info and if it’s not enough ask again

This one is the most useful to me. Always try to ask for why, how and what… Why is it important for the business? why would it be useful for the team? why do you think it provides value? how much is gonna impact the team to implement this? what are the implications of use this?

Try to always look for the answer that will make more sense for the team and the business that actually provide a useful benefit. Don’t fall in answers like “F*ck it, let’s do it”, “this might be useful in the future”, “let’s implement it and see what happens”. Try to prove that the hype is worth it by doing a small PoC and see how it works, never ever try to use a new tool without knowing possible results.

Gather Feedback

Don’t listen to one person only. Try to be informed and try to understand, as much as possible, the hype of this. Maybe from other colleagues, the internet, Reddit, stack overflow, GitHub… You won’t know if the proposed tool will really add value to your business if you don’t listen to other people.

Software Design Decisions made by the team must not be taken lightly

One of the main focuses of your software design / architecture should be the ability to adapt to the change. However, when it comes on changes, I believe it must be an informed one and should taken with care. You and the team must be extremely cautious when you decide when to use a tool / framework in your platform since, again, will potentially impact the way everyone works, the and (possibly) how the business works; and how I mention mentioned before, a PoC will help you to understand all the possible implications of using a new tool. The usage of a tool / framework in conditions where is not the right one is absolutely worse than not having it.

Conclusions

At the end, i’m not trying to encourage you to be afraid of changes. Every software engineer must embrace changes. I’m encouraging you to be more informed and cautious when it comes to this.

Every time that you will use a new tool / framework, always think if it’s going to provide value to the team, the client, the product, the business, productivity, etc. Try to make smarter decisions and don’t fall in the hype, you may regret it later.

If you really liked this post, consider doing a small donation to buy me a coffee. I love coffee! 🙂 ☕ https://www.buymeacoffee.com/fern

🙌 Thanks for Reading 🙌

Dependency Injection Made Easy for VueJS and Vuex with TypeScript

Fernando Alvarez — Sun, 26 May 2019 16:52:37 +0000

Image by @mriverodorta

I have to admit it (and this is my personal point of view). Dependency Injection is not popular in the VueJS Ecosystem and, dare I say, in the JS ecosystem. People want to get stuff done quickly and nicely and that is absolutely fine but I feel that most of the SOLID and OOP principles are lost in the JS ecosystem but let’s talk about that in another post 😛

To understand Dependency Injection and its benefits, I absolutely recommend you to read this post first:

A quick intro to Dependency Injection: what it is, and when to use it

Dependency Injection was kind of hard to implement in a VueJS application since it required to do a couple of tweaks to the codebase. One of the DI (Dependency Injection) solutions for JS and TS out there is InversifyJS which is my favorite DI container but still hard to use with VueJS. Fortunately, that is no more and one person give us, which is to me, the solution to implementing DI in our VueJS Apps.

In this guide/practice, I want you to learn about how to implement Dependency Injection easily into your VueJS project with TypeScript using the library Inversify Props

CKGrafico/inversify-props

Game Of Thrones (HBO)

Complete Example

If you want to take a look into the complete example, you can go directly to this link!

jefer590/vuejsdepencyinjectionexample

What do I need?

Install the latest version of yarn andVue CLI
An editor compatible with TypeScript (I love WebStorm for this)
Clone the base repo for the exercise.

What are we building?

A super simple app that:

First, will use a service that connects to https://api.kanye.rest through a component
Then, the same behaviour but through a Vuex Module

Getting Ready

Clone the next repo in your machine:

jefer590/vuejsdepencyinjectionexample

and then instal the dependencies using

$ yarn install

Creating the Service

In the /src folder, create a new folder folder called services and inside the new folder, create a folder called impl

The /services root will be used to expose easily the Service Interfaces
/services/impl will be used to add the concrete implementations of our interfaces/services

In the /services folder create the file IKanyeWestService.ts with this shape:

We return a promise since we will retrieve the quote from an external service.

It’s time to do the concrete implementation! Create a file called KanyeWestService.ts in the /services/impl folder. It should have this shape:

In this class service, what basically does is a wrapper of our axios HTTP call which will return the object data that corresponds to the quote. You might ask:

Why didn’t you do the http request inside the required component?

The answer is easy! It’s easier to maintain. By creating a decoupled service from our codebase and injecting it in the whole codebase, let us have our code in only and only one place. If for some reason the library changes in the future (maybe they change from HTTP to Protobufs) we need to only do the change in one place and will take effect basically in every part where the dependency is injected. We will be using the abstraction over the concrete implementation.

The Dependency Container

Create the Container

In the /src folder, create a file called app.container.ts which will be the file where we are going to register all of the dependencies with its abstractions. the file should look like this:

Register Dependencies

Let’s bind our dependencies!

In the same file, import container from inversify-props and both files that we did for the KanyeWest service. Inside of the function we will use container to register our service in this way:

To this to take effect in our codebase, in the main.ts you will import the function from app.container and use it inside the loadDependencyContainer

Injecting a service into a VueJS Component

Our dependency container ir ready! Now it’s time to use it inside a Vue Component.

Go to to /App.vue and start by importing the IKanyeWestService and then a decorator from inversify-props called Inject

And to inject this service, just simply add this piece of code in your Component class:

and… That’s it! It literally take a few lines of code to use a dependency by using DI with this library. The only things left are:

Fetch the quote when you click the button.
Fetch the quote when the component is loaded.

To tackle both cases, in the method getQuote use the injected dependency and set the quote text into the data which is called quote

and to execute this when the component is loaded, just put it in the mounted hook method. At the end, your script should look like this:

Now that we have a fully functional component with an injected dependency, we can do the same for Vuex using vuex-class and vuex-module-decorators

Use Vuex in App.vue

Let’s first remove the content of the method getQuote, remove the injected dependency from the class and then remove the imports associated to the injected dependency.

Now import the Action and Getter decorators from vuex-class and use Getter above the quote data to bind it to the quote getter in the store:

For the Action, since we are binding functions, we will need to match the function type in the next way:

And use it inside the getQuote method. The component script should look like this:

DI inside a Vuex class module

The last part of this guide is doing DI in a Vuex module using vuex-module-decorators and inversify-props which is as easy as the component approach and, dare I say, the same code.

go to /store/modules/KanyeWest.ts and import the same inject and Interface service that we used in the component into this file

And using the same approach as the component, Inject the dependency:

and that’s pretty much it! Let’s us it in our fetchKanyeQuote action:

And voila! Our project is finished and using DI!

And that’s it for today! I hope you learned a little bit about Dependency Injection on VueJS and TypeScript. Feedback is welcomed!

🙌 Thanks for Reading 🙌

Nuxt.js Debugging for WebStorm

Fernando Alvarez — Sat, 30 Mar 2019 15:56:44 +0000

The very first recorded computer bug (The Next Web)

Did you ever try to debug a problem using only console logs? did your head hurt before and after this? did it take a long time to find out it was a missing property in an object? Let’s face it… almost everyone had to recur to this method, including myself.

console.log is not and will not ever be a silver bullet for debugging

Debuggers are tools that have been between us for years but for some reason people stop to use them in the NodeJS world. Our friends from NodeJS, VSCode and Jetbrains have created a plenty of tools that help us to “stop” the application and get the current state of the application in that moment in time.

NuxtJS, in the other hand, have been a pain in the ass to try to get the debugger up and running, has been so hard to figured out that people tend to just drop the race and start to use console.log.

Everyone trying to get NuxtJS debugger running, including myself

Well, fear not my friend! I actually have a quick, safe and nice solution for all your problems! Actually, NuxtJS debugging is easier than everyone think and I want you to know this since there’s almost NO documentation of the subject and want to make your life easier.

Project Config

Open your nuxt.config.js and go to the build property because we are going to modify the extend method.

We need only add one line of code but is extremely meaningful to enable debugging:

What does this line mean to us?

config.devtool is a property of Webpack that let us configure how the SourceMap for that JS should be generated (Reference)

eval-source-map is a SourceMap that matchers exactly to the line number and this help us to debug in the client. (More Info)

inline-source-map is very similar to the last one but with the exception that is added as DataUrl in the bundle. It help us to debug our NuxtJS app in the server. (More Info)

Note: Try adding a development environment validation. It’s not recommended to use this on production.

Running the NodeJS Debugger with nodemon

We will use an excellent tool for development called nodemon which basically let us watch any change in our project and restart the server automagically.

To run the NodeJS debugger with nodemon just add the flag --inspector and that’s it!!

WebStorm

Open your project with WebStorm and wait for everything to be indexed.

Configure Server Side Debugging

Click on “Add Configuration”

Click in the plus sign and then in npm

In command use run and in scripts use dev and save!

Configure Client Side Debugging

Go to the same Add Configuration place

Click the plus sign and click in Javascript Debug

Put a name to this; URL should be the URL where Nuxt will run, browser can be your favorite one but i’d recommend to use Chrome and enable the option of “Ensure breakpoints are detected when loading scripts” and save!

How to get both running

First run the Server Side Debugger by having the run option selected and then running the bug

After the project loads correctly, select the client side run config and click the same icon. It should open a new chrome instance.

And we are absolutely ready to debug our application! 🎉

Demo Video!

Have a great hunt, Bug Hunter! May this article were of your help in your job!

The Hunter from Bloodborne (From Software)

🙌 Thanks fo reading! 🙌

Level Up your VueJS project with Typescript (Part 3): Vuex

Fernando Alvarez — Mon, 14 Jan 2019 13:30:25 +0000

If you missed part 2, go to this post:

Level Up your VueJS project with Typescript (Part 2): Translating Components to Typescript

For the complete version of this part, use this branch of the project repo:

jefer590/upgrade-vuejs-ts-series

In part 3, we translated most of our components to use Typescript using the vue-property-decorator with the exception of the View that use Vuex. In this part, we will translate our Vuex Modules and the Store.vue that uses the module. Let’s get started!

The Foo Vuex Module

If you noticed, the project already has a Vuex Module called Foo in the path ~/src/store/foo.ts. Go to that file because we are going to modify it.

Let’s take a look what’s “inside” of this simple module. The module contains a state called text which initializes a simple text string; contains a mutation to set a new text into that state; a getter to get the text string but in upper case and last the module is namespaced so, to access to this, we will need to use Foo/textUpper if we need the getter for example.

Taking all of this into account, let’s remove all the content of this file because we will rewrite the whole file in Typescript but doing the same actions and preserving the same state. For that we will use the library (installed in part 1):

championswimmer/vuex-module-decorators

Translating the Foo Vuex Module into Typescript

We will start by importing the necessary decorators and classes that we will use in the *Foo * Module:

import { VuexModule, Module, Mutation } from 'vuex-module-decorators'

In the “traditional” way, we return an object literal that contains all the states, mutations, etc; to satisfy our requirements. For this approach, we need to return a class that extends of VuexModule and the name of the class needs to be the name of the module which in this case is Foo

The only thing left to let know to Vuex that this file/class is a Module and is namespaced is use the @Module decorator at the beginning of the class and we will pass metadata to the decorator to let know this class is, in fact, namespaced:

Our Foo Module looks good but the state, mutation and getter are missing. Time to work!

To add a state to the module we will simply add a class property that needs to be public and the name of the property needs to be text and we will initialize it with the same string text as the “traditional” way:

For the mutation, we will do a class method that uses the @Mutation decorator. The name of the mutation will be defined by the name of the class method. The parameters of the class method mutation will only be the required ones to mutate the state. There’s only one catch here and is, to access to the state of this module, you will need to use this for example: this.text

And last, to create a Vuex getter, you need to define a class getter like computed properties in the Vue Component class. The name of the class getter will be the name of the Vuex getter.

https://medium.com/media/3ae7397c9f1eadd6dfd47ae0cd07fe56/href

And that’s it! if you test the project with yarn serve and see that the Store View is still working that means that the Vuex store module is using our TS implementation of it successfully 🎉

Translating Store View to Typescript

We go to ~/src/views/Store.vue and take all the part into another file because we will delete the current script content. We will define a class component following the same pattern as part 2:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/e54690ed663e61c2aa1475dc6868e83d/href">https://medium.com/media/e54690ed663e61c2aa1475dc6868e83d/href</a></iframe> <p>To create the Vuex bindings, we will use a library that I really like called vuex-class this will let us to create the bindings of our Vuex store using Decorators (already installed in part 1).</p> <p><a href="https://github.com/ktsn/vuex-class">ktsn/vuex-class</a></p> <p>In this component, we need to bind the state text, the mutation setText and the getter textUpper into it. Let’s begin!</p> <p>Since our Vuex state is inside a namespaced module, we need to create the binding for that namespace. First import:</p> <p></p> <div class="highlight"><pre class="highlight plaintext"><code>import { namespace } from 'vuex-class' </code></pre></div> <p></p> <p>Then, we will create a constant <strong>outside the class</strong> that will have the Decorators of our namespace. Using namespace as a method, you need to pass, as a parameter, the name of your namespaced vuex module so we will pass the name <em>“Foo”</em> as follows:</p> <p></p> <div class="highlight"><pre class="highlight plaintext"><code>const fooModule = namespace('Foo') </code></pre></div> <p></p> <p>Our script of that component should look like this:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/6f691ac0645ef94906f91f4d1ca58aab/href">https://medium.com/media/6f691ac0645ef94906f91f4d1ca58aab/href</a></iframe> <p>Great! time for bindings! Our first candidate is the text state. To use the namespaced state, we will use the const fooModule as decorator and the state will be a class property with the same name as the state and taking into account the proper types used in the module:</p> <p></p> <div class="highlight"><pre class="highlight plaintext"><code>@fooModule.State private text!: string </code></pre></div> <p></p> <p>Our script should look like this:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/dad0e29ab8218c3d903c4b9cec188667/href">https://medium.com/media/dad0e29ab8218c3d903c4b9cec188667/href</a></iframe> <p>Now it’s time to bind the getter. For that, we will follow the same pattern as the state:</p> <p></p> <div class="highlight"><pre class="highlight plaintext"><code>@fooModule.Getter private textUpper!: string </code></pre></div> <p></p> <p>Our script should look like this:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/30282cd455a3d0083dc72de46fa373c7/href">https://medium.com/media/30282cd455a3d0083dc72de46fa373c7/href</a></iframe> <p>Last but not least, it’s time to bind the mutation. We will follow the same pattern as the getter and the state BUT with a little catch in the type. The type <strong>must</strong> match the method input and output types. Fortunately, Typescript let us do this to our variables:</p> <p></p> <div class="highlight"><pre class="highlight plaintext"><code>@fooModule.Mutation private setText!: (_newText_: string) => void </code></pre></div> <p></p> <p>In this case, we are telling to the typescript compiler that this property is a method and will receive a string but it won’t return nothing by using void. After adding this, the scriptshould look like this:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/0620325c94725092402b7280d8762317/href">https://medium.com/media/0620325c94725092402b7280d8762317/href</a></iframe> <p>We are almost done! The only missing thing here is a method used in the input’s @input event method called changeText that will pass the event param with the new value and will use the mutation to change the state of text :</p> <p></p> <div class="highlight"><pre class="highlight plaintext"><code>changeText (event: _any_): _void_ { _this_.setText(event.target.value) } </code></pre></div> <p></p> <p>The script now should look like this:</p> <iframe src="" width="0" height="0" frameborder="0" scrolling="no"><a href="https://medium.com/media/7ca1d98d2114fc18b3759d32d3f0dbec/href">https://medium.com/media/7ca1d98d2114fc18b3759d32d3f0dbec/href</a></iframe> <p>And that’s it! If we run our project with yarn serve and check again the Store view, everything should still working as expected!</p> <h4> <a name="thats-all-for-part-3-stay-tuned-for-part-four-where-we-are-going-to-create-a-new-endpoint-api-in-express-using-typescript-but-also-we-are-going-to-create-a-new-view-that-will-use-that-endpoint" href="#thats-all-for-part-3-stay-tuned-for-part-four-where-we-are-going-to-create-a-new-endpoint-api-in-express-using-typescript-but-also-we-are-going-to-create-a-new-view-that-will-use-that-endpoint" class="anchor"> </a> That’s all for part 3! Stay tuned for part four where we are going to create a new endpoint API in Express using Typescript but also we are going to create a new view that will use that endpoint. </h4> <h3> <a name="thanks-for-reading" href="#thanks-for-reading" class="anchor"> </a> 🙌 Thanks for reading! 🙌 </h3>

Level Up your VueJS project with Typescript (Part 2): Translating Components to Typescript

Fernando Alvarez — Mon, 07 Jan 2019 13:31:00 +0000

If you missed part 1, go to this post:

Level Up your VueJS project with Typescript (Part 1): Installing Typescript

For the completed version of this part, use this branch of the project repo:

jefer590/upgrade-vuejs-ts-series

In part 1, we prepared our project to use Typescript and was only installation + configuration. For many of you that part could be considered the “boring” part and I understand it! To compensate that, in this part we will translate almost all our VueJS Files (Home View+Components) to use Typescript! So let’s begin.

Translating the “Hello.vue” Component — Single File Component

For this component, we are going to replace only the <script> part with TS, the HTML template doesn’t need any modifications (one advantage of using SFC 🙌).

When we open this file we noticed that the file is very simple:

The component data is only a variable called text with a string
There’s only one computed property called textUpper that uses text

Try to remember this because we are going to delete all the script part of that component and we will rewrite it using TS starting with:

You will noticed that we added a lang="ts". This means that we are telling to Vue Loader the script inside this SFC will be compiled/transpiled using Typescript.

After that, we will use a library that I absolutely love for VueJS TS development called vue-property-decorator that is already included in the project

kaorun343/vue-property-decorator

And using that library, we will start to use this pattern for every component that we will make with TS

Now you may ask, “what does this even mean?” let me explain it quickly:

@Component is using a feature in TS called Decorators and in this context will pass some metadata of the component to the class. The metadata is basically all the properties that are available in the VueJS Component like data , methods , components , mixins , etc…

In export default class Hello Extends Vue we are doing almost the same as the traditional way that is exporting the VueJS component object but we have TWO main differences:

The class name will be also the name of the component
Since this is Typescript, we need the VueJS object to be inherited to have the types available and also to tell to VueJS that this is a component object.

To declare the textdata or any kind of data in your VueJS component, create simple a class property and initialize it with the “Hello” string:

private text: string = 'string'

this line is pretty much the same as:

and to create the textUpper computed method, we need to create a “getter”inside our component class

which, in the traditional way, translates to:

After that, our “Hello.vue” Component should look like this:

If you run the project with these changes you will notice that everything is working as expected.

Translating the “World.jsx” Component — TSX Component

For this file, the first thing we need to do is rename it to use the .tsx file extension. If you are running the project, the hot reloading will fail because the compiler is not accepting how this file is done. Let’s translate this!

First, copy all the content of the file and put it somewhere else because we are going to totally rewrite the World.tsx file. After you clean the file, we will declare our Component class in the same way as the Hello.vue file:

Let’s do the same as the Hello.vue with the data and computed property!

Since this is a TSX file, a render function will be needed. To type that function, the parameter of h needs to use the Vue.CreateElement Interface and the render function needs to return Vue.VNode which translates to the “HTML” returned in that function:

This is a good amount of code to check if everything is working. After trying, it will appear an error like this:

To fix this, in the Home.vue view, change the import of World.jsx to use TSX instead. After that, the project should run fine with the only problem that our text is not updating. Since this is TSX/JSX we need to attach the events manually. To fix that, we need to add a method to the on-input event of our input and create a class method that changes the value of text to use the passed text.

After this change, the text mutation should work fine!

Translating the “Home.vue” View

The only thing left to update for now is the Home.vue file. Go to the file, copy the component imports and delete the script part. We will follow next the same pattern to create a class component but adding the component imports:

And to attach the Hello and World components, we will use the @Component decorator by passing an object with the components key as if it were a traditional VueJS object:

After save, the project should start to work properly again.

That all for part 2 friends! Stay tuned for part three where we are going to translate the Vuex module to use Typescript and also how to use it inside a Typescript Class Component!

🙌 Thanks for reading! 🙌

Level Up your VueJS project with Typescript (Part 1): Installing Typescript

Fernando Alvarez — Wed, 02 Jan 2019 13:58:01 +0000

Welcome to this new series/course! The goal of this series is that we’re going to take a simple VueJS project and upgrade it to use Typescript! You may wonder, “why to use typescript in my VueJS project if I’m fine with the good old fashioned way?” The answer is simple. There are sometimes that our project can get bigger than we expected and creating new features or a simple refactor could scare us. This is because, most of the time, we don’t have any idea if something else gets broken or how many files need to change to put our feature/refactor in place.

Requirements

Clone this project on Github and checkout the master branch.
NodeJS
yarn package manager.
Vue CLI 3.
Editor/IDE like VSCode or Webstorm.

How is the project currently working?

The project is quite simple:

We have a view with two components that basically do the same but one is done with the Single File Component Pattern (SFC for short) and the other one is using JSX.
The other view is just a component linked to a state and a getter in the foo store. It have a textbox that let us mutate the state in “real time” and see the changes right away.

We will add another view in a later part but for now this is a pretty good example.

What is the goal at the end of this series?

At the end of this series:

The Project:

Should have all their components migrated to Typescript.
Vuex Store should be also migrated to Typescript.
Typescript in Express should be in place also.
Dependency Injection / IoC Container implemented.

And you will learn:

Little bit of TS.
How to implement a VueJS Component using TS.
How to install TS in your current VueJS project.
How to use Express with TS.
How to implement Dependency Injection / IoC Containers.
How to create a vuex store with TS.
How to use Vuex within a component in the TS way.

If you want to see the completed project, click down here👇!

jefer590/upgrade-vuejs-ts-series

Mulan by Disney

Installing Typescript

The first thing that you need to do is clone the repository mentioned above in your machine using git

$ git clone [git@github.com](mailto:git@github.com):jefer590/upgrade-vuejs-ts-series.git

After that, we just install the project packages using yarn and then we check if our project is working as intended

$ yarn install
$ yarn serve

Now it comes the tricky part. To install Typescript into this project, we will use the “magic” of Vue CLI 3 by just typing the next command inside the project’s folder:

$ vue add @vue/typescript

It’s going start to install some dependencies and then it will ask:

? Use class-style component syntax? (Y/n)
? Use Babel alongside TypeScript for auto-detected polyfills? (Y/n)

We say yes (Y)!

And after everything is installed, that’s about it! You already have Typescript on the project! but you may noticed some weird stuff happened. Let me list:

Every .js file was renamed to use the .ts extension.
Add the VueJS and TSX Shims to the project.
The CLI Replaced the Home.vue and App.vue with the default ones (😱)
The CLI Added the HelloWorld.vue component

and if you try to run the project is not going to work because the TS compiler is failing. Let’s fix all these problems!

Stabilizing the project

To recover the Home.vue and App.vue files, we only need one git command:

$ git checkout HEAD -- src/App.vue src/views/Home.vue

We can remove the HelloWorld.vue component
Since our store started to use TS instead of JS, we need to type our store module. Go to src/store/foo.ts andtype your function params in the next way:

After all of this, if we serve again our project should work fine without any compilation errors.

Installing Extra Packages

For this series we will install a couple of tools that I, personally, love for my day by day TS development in VueJS. I’ll explain both packages in the future so don’t worry about it for now.

we only need one command with yarn to install both packages.

$ yarn add vuex-class vuex-module-decorators

and to support the vuex modules decorators we only need to add the next config almost at the end of the vue.config.js

transpileDependencies: ['vuex-module-decorators']

so, our vue.config.js should look like this:

Let’s test our project! If we run…

$ yarn express

and then…

$ yarn serve

The Express API and the VueJS Site should work! 🎉

That all for the first part folks! Stay tuned for part two where we are going to translate some components to Typescript.

🙌 Thanks for reading! 🙌

Documentation with Continuous Delivery Pipeline using VuePress, S3 and Buddy Works

Fernando Alvarez — Mon, 30 Jul 2018 11:01:01 +0000

The other day, I was told I can create a Continuous Delivery pipeline for the documentation for the project and I said yes and for this particular case we use VuePress, which is the new tool by Evan You, the creator of VueJS, to create documentation for your site. We create something simple for it but the curiosity of how can I improve the pipeline started to work and then, this article came up.

Prerequisites

An AWS Account
NodeJS (Version must be ≥ 8)
Yarn
A Buddy Works CI/CD account
A Github Account

Code Ready Example

If you just want to test the pipeline and skip the development part (doing your own documentation), you can fork this project ready for S3 deployment and start experimenting with it.

jefer590/vuepress-s3-cd-example

Setup Project

First we will need to init a new NodeJS project using yarn using the next command:

$ yarn init

Then, it’s time to install the only dependency for this project that is VuePress

$ yarn add -D vuepress

After that, you must follow the Getting Started Guide of VuePress. If you have it ready, let’s move on!

Setup Pipeline

Create a new public or private project on Github, you can name it however you want.

We need another config before jumping into Buddy Works and that is creating a programmatically user on AWS IAM that will allow Buddy Works, deploy the built assets into an S3 bucket and, obviously, an S3 bucket configured to support Static Web Pages.

In the AIM dashboard, you have to go to Users > Add User and then, in the next page, you will write the AIM username with programmatic access

In the permissions screen, you will attach an existing policy. For demonstration purposes, we will use the “AmazonS3FullAccess” policy. You can create your own policy with only the necessary permissions for Buddy Works and you can check them in this link

In the next screen, verify the info for your user and click on “Create User” and in the next screen you will get the Access Key ID and the Secret Access Key. save this info because you will use it later.

Our user is ready, thanks IAM!

It’s time to create our S3 Bucket! go to the S3 dashboard and click in the button “Create Bucket” and a modal will appear to start creating the bucket. On the first step, add a bucket name that will be part of your domain name and select your preferred region.

On the next step, you will add “Versioning” to the bucket. Static Web Site config comes later.

Next step, grant read access to all the users.

The last step is review your options and that’s it! you have a brand new S3 bucket but only one thing is left, set up the web host for this bucket and for that, in the dashboard of your bucket, go to Properties and then click on “Static Web Hosting”

A bunch of options will appear again, click on “Use this bucket to host a website”. On Index document you will put the value “index.html” and on Error document you will add the value “404.html”. Both files are generated by the VuePress building process. You save and that’s it! Everything is ready on AWS.

Now let’s go to the fun part, configure the pipeline! Go to your Buddy Works Projects dashboard and click on “Create a new project”

Then, a list with all your repos will appear. Search the one that you created for the VuePress Project

After you selected your project, the pipeline dashboard for that project will appear. Click on “Add a new pipeline”

In the next screen, we will set how the pipeline will be triggered and which branch or tag you want it to be triggered. In my case, I’ll trigger this pipeline every push to master. You can add a target website to preview the deployed project. For this case, we will use the S3 static website url which the pattern is .s3-website-.amazonaws.com

After that, a screen to chose a new action for your pipeline. Since we need to build the VuePress project to upload it into our S3 bucket, we will use a node action.

Time to configure our task! We need yarn to build download the packages and download everything, so let’s install yarn in this action. Go to “Environment Customization” and add the next command $ npm install -g yarn and to try that yarn is installed, in the command screen, use the$ yarn -v command. Save the action and let’s run manually our task clicking in the “Run Pipeline” button

If everything went fine, check the logs of your node action and you will see the latest yarn version

All right! Yarn is ready in our pipeline, let’s add the build action into out Node Task! Use the command $ yarn and$ yarn build:docs to install dependencies and build the docs.

The last thing needed is set the Node Runtime to grab the latest 8 version of node from the Docker Public Hub

At last, we have our first action made on node!!!

Our brand new action is ready!

The build should be good! Now let’s actually upload all our documentation into our S3 bucket. Create another action for the pipeline but this time search for a S3 action. It will ask for you S3 User Access Key ID and Secret Access Key. Use the one that you created with the S3 policy.

If the integration went fine, a screen with the S3 upload config should appear. Make sure that you are using the “Pipeline Filesystem” to use the build archives in the past action and make sure that your source path is /docs/.vuepress/dist

Also, make sure that you will use the S3 account for this action and you will upload everything to the root of the bucket with public access. At last, set a name for your action.

Click on “Add This Action” to finish and have our second action in our pipeline

Everything is going well, we have a step to build and a step to upload but I think the only thing left is an action to notify me when this was deployed successfully. Let’s do that with an email by creating a new email action.

Let’s add a successful message to the email that we are going to notify

And at last, let’s add the name of the action.

Our pipeline should looks like this.

Beautiful!

Now, it’s the time of truth. let’s test our new pipeline by clicking on Run Pipeline button. If everything was successful you may see your pipeline as completed and you may received an email.

Everything went right on Buddy Works!

I received the email!

And, of course, our site must be online.

Our site works wonderfully!

The work done in the repo looks nice!

Conclusion

With buddy we can create CI/CD workflow so nice, so easy and so wonderful. VuePress is an excellent tool for Static Documentation because of the uses of Markdown + Vue Componentes + templates. If we keep uploading changes to this repo, the repo will trigger automatically. I suggest you to check it out!

🙌 Thanks for reading and see you on the next time 🙌

Serverless-Side Rendering With AWS Lambda & NuxtJS

Fernando Alvarez — Sat, 21 Apr 2018 00:49:49 +0000

There are two things that I love right know:

Serverless Ecosystem like AWS Lambda
The VueJS Ecosystem

One day, I was discussing with some folks in the office about Serverless and Lambdas in general, how to make a lambda, how to use the Serverless framework, create your own REST API, etc.

After that discussion, and given that I am working with VueJS, a simple but crazy idea came up:

“What if we can provide server-side rendering Front End using AWS Lambdas instead of a Virtual Machine?”

I decided to take a look into it using NuxtJS because is my favorite tool for the job and also, AWS just launched the NodeJS 8.10 runtime for AWS Lambda, making this a perfect moment to test this idea and the new runtime.

Where to find the example?

If you want to directly jump to the final version of the code, the repo is available in github right here:

jefer590/serverless-side-nuxtjs-example

Prerequisites

An AWS Account
NodeJS
Serverless CLI
Yarn (You can use npm)

Setup

First we will need to init a new NodeJS project using yarn (or using NPM) using the next command:

$ yarn init

Then, it’s time to install the dependencies what we will need for this project:

$ yarn add aws-serverless-express axios express nuxt

but, what are these dependencies? let me explain briefly:

ExpressJS is a minimalist framework for web development for NodeJS
aws-serverless-express is a proxy to run express applications in AWS Lambda (The spine of this project)
axios is a HTTP Client for NodeJS and Web Browsers
NuxtJs is a Server Side Rendering Framework for VueJS

After installing all the dependencies, we will need a serverless plugin to make this whole thing to work:

$ yarn add -D serverless-apigw-binary

This Serverless plugin automates the process of adding binary files support in API Gateway. (From the Github Repo)

Now, is time to add some scripts to our package.json:

... "scripts": { "dev": "nuxt", "build": "nuxt build", "deploy": "npm run build && sls deploy" }, ...

“dev” is to run nuxt locally and test if our pages and layouts work properly
“build” is for building the scripts and assets that NuxtJS require to serve static html
“deploy” runs project building and uses the Serverless CLI to deploy our function in AWS Lambda.

Configuration

First of all, we need to some config related to NuxtJS and Serverless

NuxtJS Config

In our root folder we will create a file called nuxt.config.js a file designed to contain all the config that NuxtJS needs to be built and run properly. You can check the documentation of the config file in the NuxtJS Site.

I’m just going to point the important parts of this file:

srcDir: 'src/', performance: { gzip: false }, router: { base: '/dev/' }, dev: false

“srcDir” is self-explanatory; is the path of where all the source files live in the project.
“performance>gzip” is for performance configurations, since we don’t want gzip based request (not quite well supported by AWS Lambda), we just disable it.
“router” is the web path where NuxtJS is going to be triggered, maybe you want the frontend to be executed in /site/ instead of root.
“dev” a flag that tells to NuxtJS if the project will run in production mode

Serverless Config

In the root file, you will create a file called serverless.yml that contains all the config needed to deploy our Lambda function in AWS or maybe your function in another provider. You can check the Serverless YAML reference guide in the Serverless documentation.

In the provider config, we set that our function is going to be deployed into AWS using the NodeJS 8.10 runtime and in the region us-east-1 in the dev stage. Our function is going to be called nuxt and the handler of it will be in the handler.js file on the property nuxt, we will se more details of it in the code; and the events that will trigger this function will be HTTP events (via API Gateway) with Any method to any path to support the NuxtJS routing.

The custom part of all this is related to binary files in the response. Since our lambda will provide Static assets like HTML, css and JS, we will need to support these kind of file using the type */*.

Project Structure

Time to code!

First of all, we will need to create the handler.js which serves a the entry file for our Lambda

This file does a couple of things:

First, we import our server.js that contains all the config related to Express Middlewares and Routing.
We use a “workaround” to serve static files from our lambda.
We create our Server object using the Express and MIME configs.
Finally, we use the Express Serverless Proxy in our lambda handler.

Express Server file

Since we are using an Express Proxy, we use the same config as always!

What does this file do?

We import the necessary packages to config Express.
We create our Express App.
We set the API Gateway Middleware.
We config the path to access to the NuxtJS static assets.
We add our Nuxt App as a Express Middleware.
We export the Express App to use it in the proxy.

NuxtJS

The time has come! It’s NuxtJS time.

We need to create two folders in the src folder, layouts and pages. The NuxtJS documentation defines these folders as:

The layouts directory contains your Application Layouts.

The pages directory contains your Application Views and Routes. The framework reads all the .vue files inside this directory and creates the application router.

You can check more info about directories in the NuxtJS Documentation.

To serve the root path of our url (Ex: https://mysite.io/), we will create a new index.vue file in the root of the pages dir

This file will render a Hello World like page, but the interesting part of this is that first it will fetch the data of Luke Skywalker from the Star Wars API using and pass it to the template to generate the HTML using the asyncData Method. The NuxtJS define the asyncData Method as this:

You may want to fetch data and render it on the server-side. Nuxt.js adds an asyncDatamethod to let you handle async operations before setting the component data.

You can check more info about the asyncData method in the NuxtJS Documentation.

The next file will be rendered like this:

Our root path is ready 🙌

Next, we will create the next paths:

/serverless To show another Hello World like page but it will use a layout for it. Will be handled by the file src/page/serverless/index.vue
/serverless/:name To show the param used in the path in a Hello {person} like page. Will be handled by the file src/page/serverless/_name.vue

Since we a re going to use a different layout for this, let’s create the layout folder and the layout to use, in my case I created a layout called serverless.

This layout will only add the Materialize CSS file to our page.

Let’s use our brand new layout in the path /serverless

What this page does is prints a data called type from our Vue object and it will use the serverless layout. It should print a page like this:

/serverless path ready 🙌

And to finish all of these, let’s create the param route /serverless/:name

What this page does, it will use a data called name that will retrieve the param use in the /serverless/:name path, it will render it in the template and then it will use it in the HTML header to generate the title and meta.description tags. The Page should be rendered like this:

It renders my name in the site and in the title 🙌

Hey Look! The title and the meta are in the HTML 🙌

Deploying

It’s time to deploy our lambda, just type the command yarn run deploy to build and deploy your app. It will take a couple of minutes.

Our NuxtJS Site built and deployed!

Conclusion

You can do almost everything in AWS Lambda! I couldn’t believe the first time I made to work this. If you have an Express powered application and you want to go full serverless, take a look to the aws-serverless-express, the migration to AWS Lambda is extremely easy and comfortable. I found a couple of use cases that you might go with this approach:

You may want to build a personal website with some degree of dynamism.
You may want to save money in idle times for your personal website.
You may want a Small Front End to be powered by a headless CMS like Prismic.

If you found more use cases or you want to discuss the mentioned ones, feel free to leave a comment!

🙌 Thanks for reading 🙌

My Experience Unscrambling a Big Content Migration

Fernando Alvarez — Mon, 22 Jan 2018 14:00:25 +0000

This article was originally published on Medium

It’s a great day at the office, the birds sing, the flowers bloom and the coffee is very pleasant. That day, the client told us about a new requirement that, at the time, we thought would be piece of cake… we were so wrong…

The client told to us that they needed to migrate all the content from their current CMS to the new Content Delivery Stream we were building. “Move content from one node to another” sounds quite easy, but there were a lot of problems to solve behind that phrase.

Old vs New

The client wanted a fancy, brand-new Content Delivery Stream including a Headless CMS, Serverless backend and a frontend to display the content of it. Their current CMS has a lot of problems: from poor client-side performance and a slow delivery stream, to server down-time.

The architecture we proposed looks like this:

High Level Architecture

CMS users can create and manage content inside a Headless CMS based on WordPress. When users publish an Article, the CMS sends it to the Content Stream. The Content Stream uses AWS Serverless Lambdas to transform and confirm the content. Content gets hosted on an ElasticSearch service. Web clients visit the frontend and can navigate on the website. The frontend was built in VueJS and Nuxt.js (server-side rendering for VueJS). The frontend fetches the data from ElasticSearch to display the content. For third-party news feeds, content is loaded using the WordPress REST API.

What are we going to move?

The requirement was clear for us:

The team needs to move around half a million articles from their old CMS into the new Content Delivery Stream. The content must be available for the frontend and for CMS users to manage inside it. The articles must show the same content as the old CMS and should be flexible enough to edit it in WordPress.

Designing the migration process

The client provided us an ElasticSearch endpoint containing all the data to be migrated instead of querying their database directly. At first we thought of doing a Migration from their ElasticSearch to our Delivery ElasticSearch to have the content ready for external visitors of the website but there was a problem with this approach: the content will not be available in WordPress to edit it and manage it. After seeing this problem, we started doing some research on getting the content “On Demand” using a similar process as the ElasticPress Plugin for WordPress. Because of the lack of time to do this requirement, we dropped the idea.

In the next iteration of this design process: we decided to insert the migrated Content into WordPress: we already had a Plugin that transforms the content and the metadata into the required schema that ElasticSearch needs; we only needed to convert every article from the client’s ElasticSearch to WordPress post schema.

For this, we thought in automating the ingest from ES client to our WordPress instance, our first choice was using the Amazon Simple Queue Service (SQS for short) to throttle the Content Ingestion. The plan was simple and this diagram was born:

We only needed a SQS Producer (to grab from ES and ingest it to an SQS queue) and a couple of SQS Consumers (to listen to the queue and insert the messages into WordPress). Our technology choice was NodeJS because there are two easy-to-use SQS Producer and Consumer modules for NodeJS available in NPM.

At the time we were developing the SQS Producer we faced an important problem: ElasticSearch’s limit of 10K documents on from + size queries was causing this problem. To solve this, we decided to use the Scroll API to access to every document in chunks.

Other problem that we faced when we were developing the Producer was that if the process died, the state wasn’t saved and everything needed to be ingested again.

To avoid this problem we saved the state of which articles where ingested. To keep track of the last ingested document into SQS we saved the UUID of that document in a database every time the process runs again. It checks the latest UUID in the database. The Scroll API then knows from where to start, using the UUID.

The consumer process was easy to make. We created a NodeJS script that would listen to the queue and it would got data in chunks of ten. After, it would try to insert them into WordPress. If the process failed fifteen times, SQS would send the broken messages into a Dead Letter queue. To keep the process alive we used PM2.

After creating the SQS Producer and Consumers, we started developing the content transformers for the WordPress REST API. At first, we decided to get every dependency inside WordPress but we started to notice the requests took a lot of time. Transforming and fetching data inside the CMS was a lot of work for WordPress and MySQL. After a tough afternoon brain storming how to solve this problem, we decided to fetch all the dependencies in the SQS Producer. We transferred that work to Node instead of WordPress to avoid Requests timeout from the API.

After that change in the Producer everything started to go fine. We decided to start testing the migration process and noticed that MySQL and PHP were taking too long transforming and inserting the data into the CMS.

We decided to use Amazon Aurora to scale up the database power. Things started to look a little bit better after that but we noticed that the process was going to take many days to finish. With around 50 Articles per minute, the whole process would take forever so we decided to scale-up, the CMS, vertically.

We created a Terraform template to create a cluster of 5 WP instances with the same big power and all of them connected to Aurora. Every request passes through an Elastic Load Balancer (AWS ELB) and using a round robin will access to each instance.

At last, we had our first architecture design of the migration process:

Architecture of the content migration using SQS

We were so proud at that moment because everything started to flow super nicely! but we knew this could be improved to speed up the process a little bit more. We decided to go to the next level by using Amazon Kinesis.

We decided to change the SQS Producer to be a hybrid supporting SQS and Kinesis ingestion. For the Consumer, we created a lambda function that gets triggered when a new event is ingested into Kinesis Stream. At that moment, we could get around 150 per minute and guess what! The process was too much for WordPress and started timing out. The answer was vertically-scaling up the EC2 instances. At last, our migration process with Kinesis was finished.

Architecture of the content migration using Kinesis

At this point everything started to going exceptionally well, extremely good time per requests, great number of requests per minute handled… Then everything started getting dark for us.

The bumps on the road

We thought at the moment we were out of trouble but we were so wrong. The first bump was when we hit 100k articles and everything came tumbling down:

What an odd peak…

We were surprised by this: we never thought something like that peak could happen in the process until we noticed something interesting:

We noticed that getting the dependencies to send it to the Delivery Stream was taking too long «but WHY!?!» We noticed that the wp_postmeta table from WordPress had around 1.5 million rows, lots of the values weren’t indexed and required lots of time for MySQL to resolve. This problem was serious because we were facing a probable design problem in the way WordPress stored the Article metadata. To solve this, we installed the ElasticPress Plugin to save all the content from WordPress into another ElasticSearch instance. Everything started to run normally again!

Before ElasticPress and After ElasticPress

Another problem we faced is, the process in Kinesis finished abruptly.

Fortunately, this just was a configuration problem that was solved easily by changing the data retention period of the event in the AWS Console

From 24 hours of retentions to a week of retention

Another problem we faced in our tests, was the number of request per minute being at an incredibly slow rate when the database had around 1 million Articles:

To solve this, the operation team suggested us to use the HyperDB Plugin for WordPress to manage easily the read and writes replicas since we are using AWS RDS Aurora as Database Infrastructure. After the configuration of the plugin, the results were very satisfying:

HyperDB helped us to manage Read and Write replicas and speed up the process.

Time to run the data migration

After all this bumps, we were finally able to run the data migration in the client’s infrastructure. We set up everything and we started the process at the first hour in the morning and after 10k articles we started noticing slowness in the process, time outs and very high CPU usage in the AWS Aurora cluster.

We made some tests again in our infrastructure and everything fine but their infrastructure wasn’t working! something fishy was going on. We were facing an interesting and unpredictable problem. So close yet so far, we started to debug the process using new relic and we noticed something interesting in their infrastructure:

Every request was taking almost 9 seconds!

126 instances!?

After some exhaustive debugging, the architecture developer found a bug in the scalability strategy, the problem was fixed and the number of instances started to look more consistent but we still noticed slowness and we found this:

Painful long requests

For some strange reason, that select was taking a lot of time and the database CPU was peaking up to 100% of usage. This problem was interesting to solve because we need to replicate the same problem in our infrastructure. We found that each post insert makes a request to that table to increase the count of terms. We clearly don’t need that for our CMS, so we made some query improvements and optimisations but the problem was still there. We decided to add a caching layer using Redis and the plugin Redis Object Cache and the result was better than we expected:

Before Caching

Painfully MySQL getting peak up

After Caching

Every request started to took less than a second

Conclusion

A valuable lesson that we learned is that data migrations are not as easy as they sound. This whole experience helped us to understand data migrations better and the learn value was very high for us. Right now, the solutions provided in this article are effectively working for the content migration. I really recommend you to be part of a development process for this kind of projects.

Special Thanks

Thank you so much to Vero Leon, Eder Diaz, Rafa Salazar and Eduardo Romero for helping me making this article even better!

🙌 Thanks for Reading! 🙌

Telegram Bot Prototype using Serverless Framework and Webtask

Fernando Alvarez — Mon, 02 Oct 2017 13:01:28 +0000

Scientists from Cognitive Science Research Group at Queen Mary University of London programmed a robot to perform stand-up comedy.â€Š–â€Š https://www.youtube.com/watch?v=fL5ZtBO4NzM

FaaS (Functions as a Service) is gaining momentum more and more popular this days because They are easy to scale, not idle times costs and incredibly powerful when creating microservices. I was told that Auth0 Inc. created their own FaaS called Webtask and one of the greatest features is that you can easily create your function using NodeJS, so I decided to give it a try and create a very simple prototype with a Telegram bot, Why a bot? Because bots are commonly known to use servers to provide their services, and I want to try the serverless approach of this. Why a telegram bot? Because I am curious about how to do a Telegram Bot.

What are we going to build?

In this article, we are going to create a very simple telegram bot that retrieves a random dad joke using the icanhazdadjoke API

What we are going to use?

Latest version of NodeJSâ€Š–â€ŠDownload it here
A Webtask account
An editor of your choiceâ€Š–â€ŠIn mi case, i’m using VSCode
A Telegram account and the Telegram Desktop Client (Recommended).
The Serverless CLIâ€Š–â€ŠDownload it here

Creating the bot in Telegram

After you created your Telegram account and logged in the desktop client, you need to talk with the BotFather (Click to go to talk with it in the Telegram Client) to create your bot and generate your API Token for your new bot.

After you open the client with the BotFather, the /start will be triggered automatically, and the bot will answer with a big list of commands that will help you to create and manage your Telegram bots

Use the/newbot command to start. The bot will need a human-readable name. I used “Dad Jokes Bot but you can use any name like “My very first super duper bot joke 5000.”

The BotFather will ask you for an username for the bot. The username must be unique and end with bot. In my case, I used “DadJokesTestBot” but the username can be any. After you insert the valid bot username will tell you that the bot was successfully created and it will give you the API Token. Write it down. You will need it ðŸ”œ.

Example of the bot’s username must beÂ unique

Creating the Webtask function using Serverless CLI

After creating our Telegram bot using the bot father, we need to create the function that will provide the bot’s functionality. In this case, we will use the Serverless CLI.

Serverless Framework provides a very easy-to-use CLI that generates skeletons of functions from different providers like AWS Lambdas, Google Cloud Functions, Microsoft Azure Functions and, of course, Auth0 Webtask.

First, we need to create our webtask function using the CLI. Using the next command

$ serverless create --template webtasks-nodejs --path <folder_name_of_your_bot_>

Our generated folder structure will look like this:

Generated folder structure by Serverless CLI

We need to do a couple of things after upload our function to Webtask. First, we need to install the webtask handler for this project that is included in the package.json file. We Only need to make this command:

$ npm install

After that, we need to install a couple of packages to make the bot work:

axiosâ€Š–â€ŠHTTP Client for NodeJS
node-telegram-bot-apiâ€Š–â€ŠTelegram Bot API for NodeJS

$ npm install --save axios node-telegram-bot-api

After installing all the project dependencies, we need to configure the function name for Webstask. Open the serverless.yml file and then modify the name of the function in service>name. The typical generated example name is webtasks-nodejs

After that, we need to login to Webstask using the command:

$ serverless login

After the login, the only thing left is deploy our function. Use the next command:

$ serverless deploy

After this, you will receive your endpoint URL, test it in your browser to be sure that is working. If everything is alright a JSON like this needs to appear:

The Webtask endpoint is workingÂ ðŸ™Œ

Setting the WebHook of our Telegram Bot

After configuring our Webtask endpoint, we need to tell to our bot where it needs to send all the requests that we could make in the chat. Telegram Bots use WebHooks. They are very easy to set up. We are going to set the WebHook to our task’s endpoint using curl:

$ curl -X POST https://api.telegram.org/bot<TELEGRAM_BOT_API_TOKEN>/setWebhook -H "Content-type: application-json" -d '{"url": "WEBTASK_ENDPOINT_URL"}'

Example of setting a Webhook, in this case is another bot that I madeÂ before

Beep-Boop ðŸ¤–: “Hello World!”

Time to code! ðŸ‘

In the handler.js file, we are going to make the bot respond to messages:

After that, we just deploy the Webtask

$ serverless deploy

And then we just chat a little bit to check if the bot responds

Any message to the bot will trigger the message “HelloÂ World!”

Making the bot to tell a random dad joke ðŸ¤¡

Lets code again!

Lets check first what this code do:

We create a TelegramBot instance.
Then we use axiospackage to call the icanhazdadjoke API.
Then we set the Token and we create an instance of the bot using the TelegramBot object.
We get the chatId and message from the current request.
If the message is the command /start, send the welcome message.
If the message is the command /tellmeajoke, we retrieve a random dad joke in text/plain from the icanhazdadjoke API and tell the joke to the user.
If there’s something that the bot does not understand, we send the error message ðŸ˜•.

Note: We can use ES2017 in Webtasks ðŸ˜

Beep-Boop ðŸ¤–: “Let me tell you a joke”

Moment of truth, lets try to chat with our bot!

It works!Â ðŸŽ‰

Conclusion

This was a simple example, but it shows how fast you can start with serverless bots. Worth to mention that Telegram Bot API is incredibly easy to use and well documented, it shows you great examples of how to create your bots and how to consume their APIs. What I liked the most of this quick project is how easy it is to get create, deploy and test functions with the help of Serverless and Webtasks. I can see a bright future for Webtasks ðŸ˜

The source code of this project is available on Github right here if you want to check it out and run it by yourself.

ðŸ™Œ Thanks for reading! ðŸ™Œ

Special Thanks!

Thanks to Eduardo Romero for helping me with the redaction and revision of this article.