DEV Community: Levi Velázquez

Important Career Advice

Levi Velázquez — Thu, 14 Jan 2021 17:08:51 +0000

Sometimes, you may hear about a tech guru telling how good he's using a specific technology or language and will try to force everybody to use it. This is a clear warning for me.

The reality, in Computer Science and Software Engineering, the more you know about something less is the understanding feeling. This is a process I describe using this simple chart.

You start getting more knowledge, you'll become more confident, but at some point, you have enough knowledge that you may realize that same as Jon Snow, you know nothing :).

Isn't bad to tell about how good u are, but forcing other people to use your methods or using your knowledge to undermine others' opinions in a bad way is just very bad. This is very common when you have a guru-tech-boss and he doesn't allow anyone to question him or think differently.

Don't be that guru-tech-boss, don't stay close to those people. If you find one, probably he isn't an expert as he tells.

Just keep learning.

When someone asks what tech should be used, a real senior answer is depends

Twitter
Portal
Dev Profile

How it started // How it's going // Desktop Setup Version

Levi Velázquez — Thu, 07 Jan 2021 01:55:42 +0000

Hi, like me, I'm sure a lot of people updated their desktop setup due to the need of working from home.

How it started // How it's going

Yep, now I prefer a widescreen monitor to two monitors, and of course it has RGB :)

Feel free to share yours :)

I'm Engineering Director in a Fintech(building apps using AWS/GCP), Ask Me Anything!

Levi Velázquez — Tue, 05 Jan 2021 01:12:17 +0000

How to Choose the Right Backend Framework (after years of experience)

Levi Velázquez — Mon, 04 Jan 2021 18:21:28 +0000

One of the most debated topics in recent years is, which backend framework should I choose. And there really is no answer, there is no framework that is better than all, they all have their pros and cons. It all depends a lot on the requirement, the domain of the problem or the platform to be developed.

Another false premise that we usually find is that we are inclined to choose a framework because of its popularity when popular does not necessarily mean better, it all depends on the need. We must remove the concept that sometimes we ourselves always want to recommend our preferred framework no matter the problem. We recommend everyone to use our preferred technology of the moment as a panacea to develop any application, without even really understanding what the need is. This is a practice that we have to learn to leave in the past, remove that chip.

Every framework has its trade-off, absolutely all have their points for and against, whoever says otherwise is because they have never encountered problems, but it does not mean that they are non-existent. But then, under what parameters should we guide ourselves when choosing a Backend framework.

We can say that there are several parameters:

Convention vs Configuration
Performance / Speed
Community
Programming language

Convention vs Configuration

To make this point into account when making our choice, we have to understand what this particular term refers to.

As the word implies, convention is a standardized, generalized practice, generally adopted by a community. When we translate this concept into backend frameworks domain, it refers to frameworks that have standard and predefined functionalities, where the developer does not need to implement them. For example, frameworks that come with session management, pre-defined middleware, authentication services, routers, Model-View-Controller management, among others. These are generally the most popular frameworks, such as Django, Rails, Lavarel.

Now, the configuration ones, contrary to the frameworks by convention, are the ones that leave most of the configuration in the hands of the developers, generally, they do not have many defined "conventions" implemented, but rather leave those implementations to the developers. They may not have authentication modules, predefined database management interface, among others. Control belongs entirely to the user. An example of this can be Tornado with Python, Fasthttp with Go, or Express with NodeJS.

Usually, this difference can also be read in some other communities like full-stack vs rest frameworks.

Now, to make a decision, as we mentioned before, we must understand the trade-off of each option, the points for or against it.

Convention

Pros:
- They are very productive frameworks, by bringing many functionalities already pre-defined or implemented, the development team does not need to waste time developing them.
- If it is a widely used framework, they are generally supported by an extensive and broad community that surely guides or drives its development to follow the best practices in the industry. This is very positive, especially for teams that do not have as much knowledge in that framework.
Cons:
- Now, those pre-defined features usually come packaged in black-boxes. This refers to parts of the code or functionalities that are obfuscated or hidden from the developer. As the famous phrase says, it works by magic. But, why this can have a negative impact, simple since if we want to change the way these standard modules work, it could represent a challenge since it implies modifying the default behavior of the framework and this couldn't be a trivial task.
- It is much more difficult to debug. Because any found error may reside inside those black boxes.
- Extra security considerations may be required since those kinds of frameworks are so well known for both good and bad, the possible ways to attack them could be huge. But nothing that a good security policy doesn't fix, right?

Configuration

Pros:
- Due to their nature, they can be adapted to many problems or needs, since as the configuration is left to the user, the developer can implement more customized flows, which would be challenging using a typical convention framework.
- Easier to debug as they have fewer black boxes than a framework by convention.
- In general, they are more efficient, since they can be used with the minimum required, avoiding overloading, in general, many times we try to kill a fly with a gun, we want to solve a small problem with a framework where we do not use even 50 % of its pre-defined functionalities.
Cons:
- Clearly, this type of frameworks, depending on the required functionality, can cause the development time to be a little longer for standardized things, this can impact the productivity of the team.
- For new programmers, depending on the type of platform that is being developed, it can represent certain complexity problems, since they will not have those guidelines that a framework by convention may have. Therefore, developers could encounter some system designing challenges. For example, if the framework does not have a defined structure for the files, in the end, this can make the project end up being spaghetti if good design decisions are not made.

So, we can conclude that if you want to implement standard functionalities, such services with database connection, authentication, CRUD management, among others, a framework by convention would be generally better. If, on the contrary, we need to implement an API with very specific functionality to our business that needs to escalate very quickly, a better approach could be using a framework by configuration. As we'll see in the next section, those frameworks generally tend to favor performance. To illustrate better, if we try to implement web-sockets in C, it will be much more difficult if we use NodeJS instead.

If productivity is a very key metric in your current work environment, as could be in a startup, the best option is a framework by convention, bearing in mind that development times would be shorter. In addition, using the most popular frameworks could guarantee that you won't have issues finding developers. Sometimes, this would impact development time and its associated costs.

Frameworks by convention

Django(Python)
Ruby On Rails(Ruby)
ASP.NET
Spring(Java)
Lavarel(PHP)
Cake PHP

Frameworks by configuration

Tornado(Python)
FastHttp(Go)
FastAPI(Python)
Phoenix(Elixir)
Express(NodeJS)
NextJS(NodeJS) It's a mix between Configuration and Convention.
Gin(Go)

Performance / Speed

These metrics are one of the most important but most difficult to measure because conceptually the meaning of performance/speed lies in different aspects. But to facilitate the conceptualization exercise, we can establish it as the impact of a request on system resources such as memory, CPU, disk, among others.

Another important point is the capacity for concurrent requests that can be handled in a certain period of time.

Finally, although not necessarily every application needs a database, it is also necessary to understand how important the relationship between our framework and it will be. Since this can greatly impact performance depending on our needs.

Now, how to choose based on performance or speed, for this, it is important to understand the number of requests that our framework will face. It is not the same to have to accept thousands of requests per second, per minute, or per hour. Therefore, before choosing a framework, it is good to review certain benchmarks (I recommend this of how it behaves under the number of requests that we will need to handle. For example, if we need to build an API to receive thousands of data from many sensors every second, maybe a framework like Django or Rails would not be the best option, it may be better to opt for a framework that handles concurrency much better like fasthttp with Go. If we need to make a hotel reservation system, maybe something like Lavarel, Rails, Django can be better due to their robustness, and tanking in count ultra-performance is not our main goal.

Here you can check a well-known framework benchmark

As you can see, if you need to handle large amounts of requests per second, traditional frameworks, do not perform well. But of course, we must take into account the domain of the problem, because it may be that the vast majority of developers do not need to handle such a high volume of concurrency. If you need more information about backend framework benchmark, you can check it out here

Regarding database connections and how the framework interacts with them is very important, currently, many frameworks have built-in ORM (Object-Relational-Mapping), which is an interface that allows queries on relational databases, but at the cost of adding extra layers, impacting the connection and queries performance. Therefore, if our application requires making very complex queries or maintaining many connections simultaneously, it's preferable to use a framework that gives you more freedom and that does not have so many layers.

Here we can see a benchmark making rest API calls that in turn, each makes 20 queries to the database in instances c3.large (R10) / m1.large (R1 to R9) EC2 instances in AWS.

As you can notice, the same thing happens as with the previous graphic, we can see big differences between conventional frameworks and most specific ones, but not necessarily that difference can be translated into positives points, because, trying to find a Rust developer could be more complicated than a spring or rails developer. Maybe if we want to implement a reservation system, with Rust it will become extremely complex, because we would need to re-invent the wheel. So we can see the trade-off: productivity vs performance.

Community

This is an important point when deciding which framework to use, since having a larger community implies that it has better support or documentation. Also, possible errors that the programmer may face, could have been documented/resolved by others.

Programming language

Web development is already a widely studied topic, therefore, we see that many frameworks that opt for a convention, follow global standards, their structure or way of working is very similar, therefore, when choosing a framework we can really reduce it to choose which programming language we want to use and to make that decision there are several variables to take into account, complexity or learning curve, community, popularity, performance, domain or purpose.

To give an example in another context, if we need to develop a hardware controller, we need to use a language as close as to machine language like C and not Python which is a scripting language. But if, on the other hand, we want to implement high-level functionalities, a high-level language is better. If we want to handle concurrency, Perl or Earlang would be a good fit.

Conclusion

I think there are two main points that can help us make a decision and that is performance vs. productivity. In general, if you are in a startup, doing an MVP or a standard product, it's best to choose a framework based on its productivity, predefined features, and standards. This will have an impact on both monetary and human resources. In this case, I would lean towards a convention framework.

In general, companies like Facebook, Google, Twitter, among others, productivity is not a problem, they have many resources and hundreds of software engineers, they can even afford to build their own frameworks, React is a perfect example, which began as a tool within Facebook and has now become a global standard. So, if you have a large team, time, a problem domain where performance is critical, I would lean towards a framework that gives you all the flexibility possible, which is generated by a configuration type.

I would like to leave a recommendation aside, never say use always my preferred framework or preferred programming language. Perfection in programming does not exist, nor will it exist. We can detect high seniority in software engineers, if when you ask what is the best programming language? the first word you answer is it depends.

If you like my content or it was helpful, you can motivate me to write more content by buying me a coffee

Feel free to ask me anything in the comments or if you have any suggestion about how to select a framework, let me know it.

I made a youtube video of this post. Feel free to subscribe, I create content about full-stack technologies.

Also, feel free to follow me here in dev.to get notifications as soon as a new post is released.

What is your favorite SQL viewer/tool

Levi Velázquez — Thu, 19 Sep 2019 22:09:48 +0000

It should be great to compile a list of best SQL viewers/tools available out there. So, based on the requirements, sometimes we need a simple interface for viewing a table, others, we need a whole tool for making more complex process over a DB (Save queries, Entity-Relationship diagrams, etc)

Let's make a list of best SQL viewer/tools in the market.

Updated list:

DBeaver
PSequel (simplest one, just for PostgreSQL)
TablePlus
HeidiSQL
DbBrowser
MYSQL Workbench
Oracle SQL Developer

AWS launches PostgreSQL Serverless Service

Levi Velázquez — Wed, 10 Jul 2019 01:48:58 +0000

Amazon just announced Amazon Aurora PostgreSQL Serverless service

The database is usually the most critical part of software architecture and managing databases, especially relational ones, has never been easy. For this reason, we created Amazon Aurora Serverless, an auto-scaling version of Amazon Aurora that automatically starts up, shuts down and scales up or down based on your application workload.

You won't need fixed RDS instances or EC2 instances with database servers attached to auto-scaling groups. This would be a good improvement regarding saving cost and scaling capabilities.

So, if you have a dev/qa environment you don't need to have a database running all the time, now using serverless service, it would be charged on-demand saving a lot of money.

For production purpose, you don't need to handle auto or manual scaling by yourself anymore. Handling traffic peaks would be as easier as any serverless(on-demand) service.

You can find everything related here

Coding Best Practices, Chapter One: Functions.

Levi Velázquez — Wed, 22 May 2019 01:51:00 +0000

My purpose IS NOT to say what is the best way to write code, some programmers have their ways and they are just fine. I just want to share with others what I consider code best practices and how to improve several aspects as readiness, structure, components, meaning, debugging, refactoring, etc.

Chapter 1: Functions

Do One Thing.

I wanted to start from the most fundamental rule and according to me, the best practice: The One Thing Rule. It will make our life easier, try to create your functions to Do One Thing.

It could be very hard to write functions that do just one thing, but it should be our ultimate goal in our daily process. Why? Let's look a this

def create_user(email, password):
    try:
        user = User.objects.get(email=email)
    catch UserDoesNotExist:
        user = User.objects.create(
            email=email,
            password=password
        )
        auth_valid = authenticator(
            user=user,
            password=password
        )
        if auth_valid:
            user.last_login = datetime.now()
            user.save()
            msg_content = '<h2>Welcome {email}</h2>'.format(
                email=email
            ) 
            message = MIMEText(
                msg_content,
                'html'
            )
            message.update({
                'From': 'Sender Name <sender@server>',
                'To': email,
                'Cc': 'Receiver2 Name <receiver2@server>',
                'Subject': 'Account created'
            })
            msg_full = message.as_string()
            server = smtplib.SMTP('smtp.gmail.com:587')
            server.starttls()
            server.login(
                'sender@server.com',
                'senderpassword'
            )
            server.sendmail(
                'sender@server.com',
                [email],
                msg_full
            )
            server.quit()
            return user

What this function does ?

If the user doesn't exist, it creates a new user.
It creates an HTML Template.
It initializes a SMTP connector.
It sends an email.

Why it is wrong ?

Is doing more than One Thing.
The unit test for that function is going to be huge and messy, why? E.g, the testing logic should consider the authentication and the welcome email process at the same time, when those process should be tested separately.
It's easier to introduce errors, let's say we want to change the welcome email, we'll need to touch our function, so, making changes in process A for fixing process B doesn't make sense.
If we try to do more than one thing, it would increase our function line numbers, losing readiness.
More things to do, it's harder to debug.

Said that, how we can try to fix or reduce the issues listed above? Let's refactor our code.

def signup(email, password):
    new_user = create_user(
        email,
        password
    )
    authenticate(user)
    send_welcome_email(email)

def create_user(email, password):
    try:
        user = User.objects.create(
            email=email,
            password=password
        )
        return user
    except UserAlreadyExists:
        raise Exception('User exists')

def authenticate(user, password):
    auth_valid = authenticator(
        user=user,
        password=password
    )
    if auth_valid:
        user.last_login = datetime.now()
        user.save()

def send_welcome_email(email):
    email_msg = create_welcome_email_msg(email)
    send_email_to(
        email,
        email_msg
    )

def create_welcome_email_msg(email):
    msg_content = '<h2>Welcome {email}</h2>'.format(
        email=email
    ) 
    message = MIMEText(
        msg_content,
        'html'
    )
    message.update({
        'From': 'Sender Name <sender@server>',
        'To': email,
        'Cc': 'Receiver2 Name <receiver2@server>',
        'Subject': 'Account created'
    })
    msg_full = message.as_string()
    return msg_full

def send_email_to(email, email_msg):
    server = smtplib.SMTP('smtp.gmail.com:587')
    server.starttls()
    server.login(
        'sender@server.com',
        'senderpassword'
    )
    server.sendmail(
        'sender@server.com',
        [email],
        msg_full
    )
    server.quit()

What we did ?

Much better, right?

We split up our create_user function into smaller functions, allowing us to separate the logic and adding a new different level of abstractions like signup function.
We applied the same principle (One Thing Rule) to the rest of the functions as well. So, readiness was improved, you can easily do unit testing and you can now change your welcome email without touching anything about user creation process.

Pro-tip:
So, how we can know when our function is not doing just one thing? the simplest way is if you can extract some logic from your function and putting it in a new one using a different logic name, most likely your function was doing more than one thing.

Level of abstraction

In order to ensure our functions are doing one thing, we should keep the same level of abstraction across all function.

In our past example (Code Preview 1), we could spot different levels of abstraction, we are authenticating the user using a
high level function authenticator(user=user,password=password) but at the same time, we're creating a HTML template from a string msg_content = '<h2>Welcome {email}</h2>'.format(email=email). This kind of function definition should be avoided.

Basically, we should be consistent at the moment we create our function. It also helps the reader to understand if our function is a high-level concept or it is a detailed process.

Sections within functions

Another way to spot if you function is doing more than one thing, if you can split it up by different sections grouping bunch of lines

def foo():
    # initialization
    # ...... several lines here
    # logic 1
    # ....... several lines here
    # Prepare return value
    # ....... several lines here

In this example, we are doing more than one thing at the same level, in order to avoid this, you can extract every section in other functions and then use them together, of course, it depends on the level of abstraction your function has.

Identation level

I encountered myself trying to understand functions with more than 2 levels of indentation. If you did as well, we can be agree
on the maximum level should be 2 as the worst case.

If you function have a lot of if/else blocks within other if/else blocks, for sure, your function is not doing One Thing. Let's see an example.

def buy_concert_ticket(user, ticket):

    ticket_price = ticket.price
    user_age = user.age

    if user.age >= 18:
        user_money = user.money
        if user_money >= ticket_price:
            seats = stadium.seats
            seat_available = None
            for seat in seats:
                if seat.is_available():
                    seat_available = seat
                    break

            if seat_available: 
                seat.owner = user
                user.money -= ticket.price
                print("Congratulations, you have a seat")
            else:
                print("There is not available seat")

        else:
            print("Sorry you don't have enough balance")
    else:
        print("You are not allowed to buy a ticket")

So, these functions allow a user to buy a ticket, but before to complete the purchase, it verifies some conditions.
This function doesn't meet our previous rules:

It has more than 2 levels of indentation/blocks.
It does more than one thing.
It has several sections.
It difficult to read due to nested if/else blocks.

How to fix this?
1.- We should try to decrease the level of indentation by removing nested if/else blocks.

def buy_concert_ticket(user, ticket):

    ticket_price = ticket.price
    user_age = user.age
    user_money = user.money

    if not user.age >= 18:
        print("You are not allowed to buy a ticket")
        return 

    if not user_momey >= ticket_price:
        print("Sorry you don't have enough balance")
        return

    for seat in steats:
        if seat.is_available():
            seat.owner = user
            user.money -= ticket.price
            print("Congratulations, you have a seat")
            return

    print("There is no available seat")
    return

You see, we were able to drop all the if/else blocks, so our max indentation level now is 2. Now, the function
has more readiness.

Pro-Tip: If you try to make simpler functions using the explained rules, you will never need to use an else again for function logic purposes.

2.- Let's identifies the things our function does and extract them to separated functions. The refactored code should look like this.

def buy_concert_ticket(user, ticket):

    if not user_has_legal_age(user):
        print("You are not allowed to buy a ticket")
        return

    if not user_has_enough_balance(user, ticket):
        print("Sorry you don't have enough balance")
        return

    available_seat = get_available_seat()

    if not available_seat:
        print("There is not available seat")
        return

    buy_seat(user, available_seat)

    return

def user_has_legal_age(user):
    user_age = user.age

    if not user.age >= 18:
        return False

    return True

def user_has_enough_balance(user, ticket):
    user_money = user.money
    ticket_price = ticket.price

    if user_momey >= ticket_price:
        return True

    return False

def get_available_seat():
    seats = stadium.seats
    for seat in seats:
        if seat.is_available():
            return seat

def buy_seat(user, seat):
    seat.owner = user
    user.money -= ticket.price
    print("Congratulations, you have a seat")
    return

We were able to extract four new functions from our existing function, it means we were trying to do too much.

Now, our main function buy_concert_ticket can be read using "natural language". Of course, I used accurate names(we're going to talk about this later on) but having a small number of lines, just one level of extra indentation, helps a lot to achieve this result.

3.- Do you think we can't make our function smaller? or reduces sections? We do, let's see it.

def buy_concert_ticket(user, ticket):

    if not user_can_buy_a_ticket(user, ticket):
        return

    buy_available_seat(user)

    return

def user_can_buy_a_ticket(user, ticket):

    if not user_has_legal_age(user, ticket):
        print("You are not allowed to buy a ticket")
        return False

    if not user_has_enough_balance(user, ticket):
        print("Sorry you don't have enough balance")
        return False

    return True

def user_has_legal_age(user):
    user_age = user.age

    if not user.age >= 18:
        return False

    return True

def user_has_enough_balance(user, ticket):
    user_money = user.money
    ticket_price = ticket.price

    if user_momey >= ticket_price:
        return True

    return False

def buy_available_seat(user):
    available_seat = get_available_seat()

    if not available_seat:
        print("There is not available seat")

    buy_seat(user, available_seat)
    return

def get_available_seat():
    seats = stadium.seats
    for seat in seats:
        if seat.is_available():
            return seat


def buy_seat(user, seat):
    seat.owner = user
    user.money -= ticket.price
    print("Congratulations, you have a seat")
    return

We could trim our main function a bit more, now we reduced it from 21 lines to just 4. We just applied the same principle,
try to abstract our logic and identifying sections/blocks in order to create new functions. This will become in an iterative process.

So, what we gained?

Anyone trying to read our function would take just seconds to understand what we were trying to do.
You can read the whole process just like a "top/down story".
Now, implementing unit test would be easier because we treated every step of buying ticket process as a single function.
If we want to add extra requirements in our process, identifying the function to change will be enough, for example: adding another restriction for a buyer, we just need to change our logic within user_can_buy_ticket() function without touching anything else.

Note: I know, doing this is time-consuming, but trust me, even when you can't iterate so many times due to deadlines, etc. Try to do it at least once. Always the first iteration brings good results.

That's all. In the next chapter, I'm going to talk more about how function parameters should be defined in order to improve readiness, giving other tips as well.

If you like my content or it was helpful, you can motivate me to write more content by buying me a coffee
Originally posted in my personal blog

What is your favorite flowcharts/diagramming tools.

Levi Velázquez — Wed, 24 Apr 2019 03:34:38 +0000

A lot of times, we need to create a flow diagram to integrate two or more APIs/Systems/Interfaces or describe certain processes. Sometimes it could be internal or we need to share with a third party.

What tool do you prefer or recommend?

Feel free to recommend one due to different characteristics: friendly interface, beautiful icons, being minimalistic, etc.

My list:

Balsamiq More for wireframes but it is pretty
draw.io Pros: It has a lot of templates and types, it has good integration with google drive. Cons: it would be nice to have prettier icons and a better shared-comments system.
Lucidchard I just started to use it, it seems pretty nice, it has a basic free version.

Complete list including recommendations from comments:

I'm preparing my first workshop, any suggestion as an attendee or organizer?

Levi Velázquez — Sun, 07 Apr 2019 20:56:10 +0000

Hi,

I'm preparing my first workshop (Full Stack), it is about Angular + Express.js + Firebase + Google Cloud Functions. Basically, the backend is going to be Serverless.

Do you have any suggestions? as attendee or organizer, what has been your experience, good/bad points about any previous workshop you had assisted.

The workshop is on site, but I have created a small tutorial regarding the backend, feel free to check it out.
Beginner's Guide for Creating a Serverless REST API using NodeJS over Google Cloud Functions

Ideas/tips for writing technical posts/tutorials.

Levi Velázquez — Fri, 05 Apr 2019 18:29:25 +0000

I have started to be more focused on writing new content, my goal is to write at least one post per week. For me, the major obstacle is finding good ideas to write about. So I have been compiling a list of topics. I want to share them, so, it could be helpful for someone looking for ideas.

Of course, your welcome to contribute to the list.

Pro-tips:

After finding the topic, the major obstacle is how to start, what works for me: use pomodoro technique ( work 45 min -- rest 15 min).
Before jumping into writing everything, you need to create an index about your article like:
- Topic 1
  - Sub-topic 1
  - Sub-topic 2
- Topic 2
  - Sub-topic 1
  - Sub-topic 2
So, you'll have the big picture and would be able to focus on writing topic by topic, it helps to get a good feeling about progressing.
My best trick: when you don't have a lot of motivation, start writing and try to spend more than 15 min without any interruption, after that, you will feel the "obligation"(motivation) for continuing.

My ideas:

Exposing localhost server to the internet (I did it, read it here)
API specifications
Date usage in Python
Serverless Rest API (I did it, you can check it out here)
Python interview questions
Javascript for beginners
Code Styleguides.
Web server vs App server
Continuous integration
Microservices
Destructing in es6
Socket.io
Push up notifications using Firebase
Creating a chrome extension
Typescript
Docker workshop (I did it, it is in Spanish).
SSH and SSH Forwarding (I did it, you can find it here)
Strings "conversions" in Python.

Shared your ideas :)

If you have any suggestions about a topic you think is important but can't find enough info or it isn't easy to catch up, comment it.

I'm Engineering Director at a Fintech(have experience creating apps using Django/Ionic/Docker/AWS(ton of it), Ask Me Anything!

Levi Velázquez — Fri, 22 Mar 2019 05:13:29 +0000

Beginner's Guide for Creating a Serverless REST API using NodeJS over Google Cloud Functions

Levi Velázquez — Thu, 21 Mar 2019 16:09:33 +0000

API REST using Google Cloud Functions (Serverless)

Serverless application has gained a lot of importance over time. It allows focussing on your app code/tests without worrying about configurations, deployment process or scalability.

We're going to create a function that will be exposed via rest URL. That function will be invoked every time a HTTP(S) request is received.

During execution, an express server will be summoned exposing our REST services.

What we are going to build?

Express API for CRUD services(create, read, update and delete) on a Firestore database.
Use Google Cloud Function to expose our Express server
Deploy our Google Cloud Function using Cloud CLI.

Creating our firebase project

In order to create our first project, let's do it here. Select add project, project's name must be unique, let's use prefix github-ring-{github_user}, github-ring-levinm in my case. Be sure to select Firestore as our database.

For creating our database, click on Develop>Database and select "start in test mode".

Initializing our project locally

We need to install firebase using NPM.



npm install -g firebase-tools

Then, let's login into our firebase account.



firebase login
........... input credentials

Initialize the project



firebase init
........ select project

It will prompt an interactive console.

Select Functions and Hosting options.
What language would you like to use to write Cloud Functions? TypeScript
Do you want to use TSLint to catch probable bugs and enforce style? Yes
Do you want to install dependencies with npm now? Yes
What do you want to use as your public directory? Press enter to select public (it is the default option)
Configure as a single-page app (rewrite all urls to /index.html)? No

We're ready, our firebase project was initialized.

Installing Express.js and dependencies



cd functions
npm install --save express body-parser

Creating our Google Cloud Function

Open src/index.ts, it will be the entrypoint for our Express.js server

Import main libraries



import * as functions from 'firebase-functions';
import * as admin from 'firebase-admin';
import * as express from 'express';
import * as bodyParser from "body-parser";

Initialize firebase for accesing to its services



admin.initializeApp(functions.config().firebase);

Intialize Express.js server



const app = express();
const main = express();

Configure the server.

Let's add the path used for receiving the request.
Select JSON as our main parser for processing requests body.



main.use('/api/v1', app);
main.use(bodyParser.json());

Export our function.

Last but not least, let's define our Google Cloud Function name, we are going to expose it using export. Our function will receive an express server object(this case main) which will be used for request processing. If you want more information regarding how it works, you can check this good answer on Stackoverflow



export const webApi = functions.https.onRequest(main);

Creating our first service

Let's expose a GET endpoint returning just a string.



app.get('/warm', (req, res) => {
    res.send('Calentando para la pelea');
})

Our src/index.ts file should look like this:




import * as functions from 'firebase-functions';
import * as admin from 'firebase-admin';
import * as express from 'express';
import * as bodyParser from "body-parser";

admin.initializeApp(functions.config().firebase);

const app = express();
const main = express();

main.use('/api/v1', app);
main.use(bodyParser.json());

export const webApi = functions.https.onRequest(main);

app.get('/warmup', (request, response) => {

    response.send('Warming up friend.');

})

Deploying our function.

Before deploying it, we need to change our config file firebase.json as follows:

{
  "functions": {
    "predeploy": [
      "npm --prefix \"$RESOURCE_DIR\" run lint",
      "npm --prefix \"$RESOURCE_DIR\" run build"
    ]
  },
  "hosting": {
    "public": "public",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "rewrites": [
      {
        "source": "/api/v1/**",
        "function": "webApi"
      }
    ]
  }
}

This rule allows "to route" all requests sent through api/v1 to be served by webApi function (Our exported one).

Also, Google CLI installs Typescript v2 by default. So, we need to update our typescript version >=3.3.1. You can do it in functions.package.json.

  "devDependencies": {
    "tslint": "~5.8.0",
    "typescript": "~3.3.1"
  },

Re-install dependencies.



cd functions
npm install

We are ready for deploying.



firebase deploy



.....
✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/github-ring-levivm/overview
Hosting URL: https://github-ring-levivm.firebaseapp.com

If everything is ok, Hosting URL will be our Google Cloud Function endpoint.

Testing our function

Let's send a GET request using CURL



$ curl -G "https://github-ring-levivm.firebaseapp.com/api/v1/warmup"
Warming up friend.

Rest API CRUD

Let's add our CRUD endpoints. We are going to manage fights information.

Create a record

First, let's initialize our database. We open our src/index.ts and add this after admin initialization




admin.initializeApp(functions.config().firebase);
const db = admin.firestore(); // Add this

In order to create a fight record, let's create POST /fights/ endpoint. Our fight record is going to have a winner, loser and title.



app.post('/fights', async (request, response) => {
  try {
    const { winner, loser, title } = request.body;
    const data = {
      winner,
      loser,
      title
    } 
    const fightRef = await db.collection('fights').add(data);
    const fight = await fightRef.get();

    response.json({
      id: fightRef.id,
      data: fight.data()
    });

  } catch(error){

    response.status(500).send(error);

  }
});

We get our post data using request.body
We use add() method to add a new fight, if the collection doesn't exist (our case), it will create it automatically.
In order to get the actual record data, we must use get() over the ref.
Return a json using response.json.

Get a record

We create a GET /fights/:id endpoint in order to fetch a fight by id.



app.get('/fights/:id', async (request, response) => {
  try {
    const fightId = request.params.id;

    if (!fightId) throw new Error('Fight ID is required');

    const fight = await db.collection('fights').doc(fightId).get();

    if (!fight.exists){
        throw new Error('Fight doesnt exist.')
    }

    response.json({
      id: fight.id,
      data: fight.data()
    });

  } catch(error){

    response.status(500).send(error);

  }

});

We get the fight id using request.params.
We validate if the id is not blank.
We get the fight and check if it exists.
If fight doesn't exist we throw an error
If fight exists, we return the data.

Get a record list

We create a GET /fights/ endpoint.



app.get('/fights', async (request, response) => {
  try {

    const fightQuerySnapshot = await db.collection('fights').get();
    const fights = [];
    fightQuerySnapshot.forEach(
        (doc) => {
            fights.push({
                id: doc.id,
                data: doc.data()
            });
        }
    );

    response.json(fights);

  } catch(error){

    response.status(500).send(error);

  }

});

We get a collection snapshot.
We iterate over every document and push the data into an array.
We return our fight list.

Update a record

We must create a PUT /fights/:id endpoint in order to update a fight by id.



app.put('/fights/:id', async (request, response) => {
  try {

    const fightId = request.params.id;
    const title = request.body.title;

    if (!fightId) throw new Error('id is blank');

    if (!title) throw new Error('Title is required');

    const data = { 
        title
    };
    const fightRef = await db.collection('fights')
        .doc(fightId)
        .set(data, { merge: true });

    response.json({
        id: fightId,
        data
    })


  } catch(error){

    response.status(500).send(error);

  }

});

We get request data.
We validate the data
We update a record using set(data, merge: true). It means it is going to update only the fields passed on data parameter.

Deleting a record.

For deleting a fight, we need to add an endpoint DELETE /fights/:id.




app.delete('/fights/:id', async (request, response) => {
  try {

    const fightId = request.params.id;

    if (!fightId) throw new Error('id is blank');

    await db.collection('fights')
        .doc(fightId)
        .delete();

    response.json({
        id: fightId,
    })


  } catch(error){

    response.status(500).send(error);

  }

});

We get the fight id.
We use delete() in order to delete a doc instance (Remember that firestore is database based on documents( "NoSQL" ))

Our src/index.ts file should looks like this



import * as functions from 'firebase-functions';
import * as admin from 'firebase-admin';
import * as express from 'express';
import * as bodyParser from "body-parser";

admin.initializeApp(functions.config().firebase);
const db = admin.firestore(); // Add this

const app = express();
const main = express();

main.use('/api/v1', app);
main.use(bodyParser.json());

export const webApi = functions.https.onRequest(main);

app.get('/warmup', (request, response) => {

    response.send('Warming up friend.');

});

app.post('/fights', async (request, response) => {
  try {
    const { winner, losser, title } = request.body;
    const data = {
      winner,
      losser,
      title
    } 
    const fightRef = await db.collection('fights').add(data);
    const fight = await fightRef.get();

    response.json({
      id: fightRef.id,
      data: fight.data()
    });

  } catch(error){

    response.status(500).send(error);

  }
});

app.get('/fights/:id', async (request, response) => {
  try {
    const fightId = request.params.id;

    if (!fightId) throw new Error('Fight ID is required');

    const fight = await db.collection('fights').doc(fightId).get();

    if (!fight.exists){
        throw new Error('Fight doesnt exist.')
    }

    response.json({
      id: fight.id,
      data: fight.data()
    });

  } catch(error){

    response.status(500).send(error);

  }
});

app.get('/fights', async (request, response) => {
  try {

    const fightQuerySnapshot = await db.collection('fights').get();
    const fights = [];
    fightQuerySnapshot.forEach(
        (doc) => {
            fights.push({
                id: doc.id,
                data: doc.data()
            });
        }
    );

    response.json(fights);

  } catch(error){

    response.status(500).send(error);

  }

});

app.put('/fights/:id', async (request, response) => {
  try {

    const fightId = request.params.id;
    const title = request.body.title;

    if (!fightId) throw new Error('id is blank');

    if (!title) throw new Error('Title is required');

    const data = { 
        title
    };
    const fightRef = await db.collection('fights')
        .doc(fightId)
        .set(data, { merge: true });

    response.json({
        id: fightId,
        data
    })


  } catch(error){

    response.status(500).send(error);

  }

});

app.delete('/fights/:id', async (request, response) => {
  try {

    const fightId = request.params.id;

    if (!fightId) throw new Error('id is blank');

    await db.collection('fights')
        .doc(fightId)
        .delete();

    response.json({
        id: fightId,
    })


  } catch(error){

    response.status(500).send(error);

  }

});

Testing

We deploy our function.



firebase deploy
....

We test all our endpoints.



# Testing create fight (POST /fights)
$ curl -d '{"winner":"levi", "losser":"henry", "title": "fight1"}' -H "Content-Type: application/json" -X POST "https://github-ring-levivm.firebaseapp.com/api/v1/fights/"

> {"id":"zC9QORei07hklkKUB1Gl","data":{"title":"fight1","winner":"levi","losser":"henry"}

# Testing  get a fight (GET /fight:id)
$ curl -G "https://github-ring-levivm.firebaseapp.com/api/v1/fights/zC9QORei07hklkKUB1wGl/"

>{"id":"zC9QORei07hklkKUB1Gl","data":{"winner":"levi","losser":"henry","title":"fight1"}}


# Testing get fights list (GET /fights/)
$ curl -G "https://github-ring-levivm.firebaseapp.com/api/v1/fights/"
> [{"id":"zC9QORei07hklkKUB1Gl","data":{"title":"fight1","winner":"levi","losser":"henry"}}]

# Testing update a fight (PUT /fights/:id)
$ curl -d '{"title": "new fight title"}' -H "Content-Type: application/json" -X PUT "https://github-ring-levivm.firebaseapp.com/api/v1/fights/zC9QORei07hklkKUB1Gl/"

> {"id":"zC9QORei07hklkKUB1Gl","data":{"title":"new fight title"}}

# Testing delete a fight (DELETE /fight/:id)
$ curl -X DELETE "https://github-ring-levivm.firebaseapp.com/api/v1/fights/zC9QORei07hklkKUB1Gl/"

> {"id":"zC9QORei07hklkKUB1Gl"}

And we are done, we have built our API Rest using Google Cloud Function (Serverless).

Note: You can check your database using Firestore interface within our Firebase console.

If this was helpful, share it :).

If you like my content or it was helpful, you can motivate me to write more content by buying me a coffee