DEV Community: Simona Cotin

Boosting your Serverless APIs with API Management at Create:Serverless

Simona Cotin — Wed, 30 Sep 2020 05:51:14 +0000

Create:Serverless

Join us for a half-day of conversations this 30 Sep 2020, at Microsoft Create: Serverless and connect with the experts and community members to discuss how you can run code for any application without having to manage servers.

Boosting your Serverless APIs with API Management

Serverless provides powerful and scalable ways to write APIs for web, mobile, and microservices. By combining Azure Functions with API Management, you can add new features like generating functions from an API definition, managing endpoints with policies and security, and rich end to end monitoring.

In this session, we'll dive into:

Why would someone working with functions think about adding API Management? What benefits does it provide?
What's the easiest way to get started with API Management and functions?
Show you how to get started with integrating Azure Functions and API Management

Want to know more? Join Jeff Hollan and Mike Budzynski on Sep 30th, at 10:25 AM (PDT) to discuss about all the ways in which you can use API Management to enhance your APIs.

New to Serverless Concepts and Technologies? Start here:

Read: Azure Functions Docs - to learn core concepts!
Create: Serverless Applications - with this hands-on tutorial.
Watch: POWERful Serverless Applications - a no-code option.
Serverless APIs in Azure Workshop.
Try Azure fro FREE

Code of Conduct

You are expected to adhere to the Create:Serverless's code of conduct as well as Dev.to's code of conduct.

.ltag__tag__id__60537 .follow-action-button{ background-color: !important; color: !important; border-color: !important; }

#mscreate

Want to keep track of these events and conversations? Follow the #mscreate tag above or follow @MicrosoftCreate on Twitter.

GraphQL and Serverless walk into a bar. A recipe to infinitely scale APIs

Simona Cotin — Tue, 22 Sep 2020 09:20:16 +0000

For a deep dive into building Serverless APIs using Hasura GraphQL join us at Create:Serverless. Allison and Burke will discuss how you can bring together your data sources into a unified GraphQL API with the Hasura GraphQL Engine & Azure Functions.

Sessions at Create:Serverless will be FREE to attend and I'm excited to be your host during the day :)

What do GraphQL and Serverless have in common?

They might seem unrelated, but in fact, both of them are very popular at the moment and have a similar trending pattern. While you're reading this article, I'm confident someone is open sourcing a new library either for Serverless or for GraphQL - awesomesauce, maybe for both - that will enable us to build amazing products more easily. The hype train, that's one thing that they have in common 🚂!

Serverless and GraphQL have seen a massive adoption with Javascript developers.

With GraphQL, frontend developers can intentionally move fast in building applications. With few exceptions, the back and forth and dependencies between backend and frontend teams are eliminated by the easiness of sharing data between the two. With Serverless, it's become a LOT easier to extend our frontend skills and build APIs without acquiring expertise in provisioning and managing servers.

Both of them have emerged around the same timeline, marking the dawn of a new era in developer productivity and tools.

Why GraphQL

GraphQL is a query language for your API and a runtime to execute those queries on your existing data. It was developed by Facebook in 2012 when they started rewriting their mobile applications to native clients. The initial goal was to define a data fetching API powerful enough to describe all of Facebook. They ended up creating a Javascript reference implementation and open sourcing a spec that help address a few very important challenges when building APIs:

Overfetching data - retrieving data that we don't need

Traditionally, to help solve this problem, we create a new endpoint that returns only the data we need or update an existing endpoint and include the required data. Whereas that can be compelling, and that's something that most of the teams do, it adds complexity to our code. We'll now have to process the response and filter out the data that we don't need on the client-side. On top of that, we have a leaking abstraction - there's now a strong coupling between our backend and frontend that reflects our client code's data needs.

Underfetching data - also known as a chatty API, when our APIs force clients to make multiple requests to perform a single operation

You might be familiar with the n+1 problem - when a request to one item turns into n+1 requests since it has n associated items. The roundtrips to the server consume valuable user data and time.

One of the reasons we need to think about overfetching and underfetching is that both directly impact our user's experience. Having to process data on the client-side and making multiple roundtrips to the server incurs a delay on our client apps, which in turn has a direct impact on the user perception:

API proliferation and lack of up to date documentation

The first two challenges lead to a high number of poorly documented and maintained endpoints that are tightly coupled to our client apps.

With GraphQL queries, clients only retrieve the data they need - they control the size & shape of the data that the API returns. Developers have access access to a single API endpoint with realtime documentation for available operations that can be run against the API.

Why Serverless

Serverless enables us to run code in reaction to events, without having to worry about managing their runtime. The platform provider will automatically scale up and down the number of resources needed to meet the current workload while maintaining reliable performance for our users. One of the most common uses cases for serverless is building web APIs for frontend and mobile applications.

What are the benefits of using Serverless and GraphQL together?

Serverless and GraphQL like any other strong symbiosis relationship complement one another beautifully.

With Serverless we get easy integration of different data sources, while with GraphQL we can easily unify multiple data sources together.

With Serverless, we get autoscalability out of the box, and with GraphQL, we get a single endpoint that will allow us to query multiple data sources.

With Serverless, we end up writing less code focusing on the problems we're solving for, and with GraphQL, we make a smaller number of requests optimizing for user performance.

With Serverless and GraphQL, we can achieve more by doing less.

Want to do more with Serverless?

Join us at CREATE:Serverless on Sep 30 (8:00am PDT / 12:30am EDT) for a 4-hr free virtual event with 8 sessions and a 50-minute hands-on workshop to jumpstart your serverless journey

Bookmark our anchor post and do check back for updates

A Deep Dive into POWERful Serverless Application

Simona Cotin — Thu, 09 Jul 2020 17:57:15 +0000

#PowerfulDevs Conference

RSVP HERE BY JULY 15:
https://aka.ms/powerfuldevsconf

The Powerful DEVs Conference is the first virtual conference of its kind. We will showcase how developers can leverage the Power Platform to build applications faster and with far less effort. Connect with industry-recognized ProDev influencers, Microsoft Cloud Advocates, trusted and diverse community leaders, and members of the Power Platform Team.

BOOKMARK THIS FOR RESOURCES AND DISCUSSION WITH SPEAKERS

#powerfuldevs Conference: Join us on July 15th Online!

JennyMEvents for Microsoft Azure ・ Jul 10 '20

#powerfuldevs #powerplatform #prodev #programming

Revisit this page during the event to engage in live (and post-event) discussions on those topics with both speakers and community. The speakers will be here for a live Q&A for at least 30 minutes immediately after their session concludes. After the event, come back to find additional slides, videos, and resources for this session.

About This Session:

July 15, 2020: 09:30 PDT – 09:55 PDT

Far from being the latest 'tech trend', serverless applications help your organization scale quickly and efficiently. They take the hassle out of provisioning infrastructure, configuring web servers, debugging configuration, and managing security settings, allowing your team to focus on coding and testing. The one aspect where serverless functions fall short is when it comes to state management. When missing state management abilities, building up complex flows in your data processing will prove to be quite daunting, and often, will require you to provide custom mechanisms for enabling you to communicate between your functions. Join this session to learn how to build serverless applications that scale seamlessly and automatically and leverage the Power Platform to create reliable and low-code applications.

Additional Resources: 25 Day of Serverless
Learn Serverless
Intro to Azure Functions

About the Speakers:

Simona Cotin is a Cloud Advocate @ Microsoft and the ServerlessDays Co-organizer. Follow @simona_cotin on Twitter.

Build your jokes generator using Machine Learning and Serverless

Simona Cotin — Sat, 14 Dec 2019 12:33:50 +0000

This article is part of #25DaysOfServerless. New challenges will be published every day from Microsoft Cloud Advocates throughout the month of December. Find out more about how Microsoft Azure enables your Serverless functions.

Have an idea or a solution? Share your thoughts on Twitter!

The Turing test has been the de facto standard for testing a machine for intelligence. It's the way we try to figure out if our models are capable of responding to general-purpose questions the way a human would. The most efficient method for building a machine that has human-like responses is using neural networks and deep learning. These are new algorithms that have been made feasible through the recent advancements in hardware performance.

One aspect of humanity that is restricted to evolved primates is humor. In all fairness, there is no clear cut definition of humor, however, there is one theory that has gained quite a bit of popularity in recent years. The argument is that what makes us classify something as being funny falls under the "incongruity theory". The underlying mechanism of this theory builds on top of the inconsistency between what we are expecting to happen and what actually happens.
As it turns out the cognitive mechanisms that allow us to identify something as "funny" are quite complex, and it is only a few evolved primates that can find something funny.
For example Koko, the western lowland gorilla who understands more than 1,000 American Sign Language signs and 2,000 spoken words has been observed making prank jokes (IE: she would tie the instructor's shoelaces and then innocently make the sign for "chase". That's one tricksy gorilla :D !).
As a rule of thumb, the primates that can make laughing like sounds and are ticklish can be categorized as having a sense of humor.

Computers, on the other hand, are not ticklish, vocal cords are not yet a justified upgrade on any of the latest generation laptops, so, by all means, training a machine to understand humor needs to be trained by other means. The best way to train a neural network is by using an exhaustive text that contains as many jokes as possible in a specific format. You will notice that we already restricted the domain of humor to jokes (no pranks, ironic comedy with complex situations etc).

"If you're willing to restrict the flexibility of your approach, you can almost always do something better."
– John Carmack"

In our situation, we want to restrict the domain of the jokes to one-liners, question style comedy which would make the training of our model more focused, essentially what we are doing is gently nudging the machine in the right direction.
The machine intelligence we are building is for text generation, a deep learning neural network that can make jokes.
We will use the language with the most evolved ecosystem in terms of libraries, examples, and documentation, which in this case, is Python. I am a big fan of Python for its readability and because it is very closely evolving alongside JavaScript so many things feel familiar, it's also the other serverless language, and this makes it an excellent candidate to
write an Azure Function that tells us jokes.
The most popular approach to writing text generation applications are based on Andrej Karpathy's char-rnn architecture and blog post,
the example teaches a recurrent neural network to predict the next character in a sequence based on the previous n characters.
Based on Andrejs work Max Woolf built a python package that makes building a text generation bot very easy. It allows you to configure your neural network depth/layers/behavior etc.

The main method for training your joke model is textgenrnn. This object has a train_from_file method that allows you to consume a file with training data to teach your bot to figure out what punch line would be best suited to answer the joke.

The usage is quite straightforward, training a simple model would look something like this:

from textgenrnn import textgenrnn

textgen = textgenrnn(name="new_model")
textgen.train_from_file('jokes.txt', num_epochs=5)

After we have trained the data from the training data set, let's take it for a spin and try generating a test joke. We can do this by calling textgen.generate(). This will output the joke, but this simple call will not return the joke from the serverless function, which means we want to use a version of the method call that returns the data.

joke = textgen.generate(return_as_list=True)[0] # Grab the first generated joke in the list, in this case the only one

The script will create the model that is a serialized version of the dataset that will be used by tensorflow to help our function generate jokes based on the training data. This is the file with .hdf5 extension in your project's root folder.

Now the last piece of the puzzle is using the new model as a trigger to generate jokes in an Azure Function. Assuming you created a storage account that has a container named jokes, here's how your function will look like:

import azure.functions as func
from textgenrnn import textgenrnn
import tempfile

import urllib.request
import os
import logging

def main(myblob: func.InputStream, context: func.Context):
    tempFilePath = tempfile.gettempdir()
    jokesfile = os.path.join(tempFilePath,"jokes.hdf5")
    urllib.request.urlretrieve(myblob.uri, jokesfile)
    textgen = textgenrnn(jokesfile)
    joke = textgen.generate(return_as_list=True)[0]
    logging.info(f"joke: {joke}")

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "myblob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "jokes/{name}",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

To test your function, upload the generated .hdf5 file to the joke container and see the generated joke in the functions logs.

Need more inspiration? You can find the source code in my github repository here.

Congrats

You now have an API with a sense of humor :D

Conclusions

You can notice that the API is not particularly funny in the classical sense, but it will surprise you. I think that what you would be expecting and what the endpoint is returning will definitely fall under the "theory of incongruity".

To improve results to match more traditional patterns, there are a few ways to improve the training method like:

restrict the type of jokes
increase training data set size

Want to submit your solution to this challenge? Build a solution locally and then submit an issue. If your solution doesn't involve code you can record a short video and submit it as a link in the issue desccription. Make sure to tell us which challenge the solution is for. We're excited to see what you build! Do you have comments or questions? Add them to the comments area below.

Watch for surprises all during December as we celebrate 25 Days of Serverless. Stay tuned here on dev.to as we feature challenges and solutions! Sign up for a free account on Azure to get ready for the challenges!