[MUSIC].
>> Let's talk about our game plan. How do we get there?
Well, if you've ever scaffolded
the function before in Azure functions,
you know that as part of what you
do is the first scaffold up a function app,
once you have a function app,
you want to scaffold up a function
because you have n number of end points in that function.
There's no difference here when it comes
to using custom handlers and using goal.
You scaffold up a function and you author your code in Go,
that's the second step and then we
try to listen to a specific route.
As the fourth-step, you try to handle the message,
which essentially means you're going
to read the message and do something with it,
which could be printing it or writing it towards a binding.
You could also be returning a response.
Now, returning a response is not a thing you must do,
this is optional if it's
the web is very customary to return something,
but let's say it's a queue message instead,
you don't actually have to return back responds to
a queue because the queue shouldn't really know about you,
so it doesn't make any sense.
But the sixth step that I'm about to show you a bit later
is to compile your Go code
because you need it to be ones and zeros.
You need it to be that executable.
>> Yeah.
>> That before you come as far as running the function,
you need to configure it and I'm going to show you
exactly how you need to configure because it's not a lot,
but you need to know how.
Looking at a very,
very simple project, if some
of you have built Azure functions before,
you will probably recognize a few of these files,
but what we are looking at after
scaffolding is a function endpoint.
Now, if you authored an Azure functions before in C-Sharp,
it doesn't look quite like this,
but you rather have dedicated C-Sharp files but
if you have authored it in JavaScript and TypeScript,
this is what you used to.
You have a route subdirectory and inside of that route you have
a function JSON and you use that function route in
JSON to configure things like triggers,
bindings, how the route pattern should be.
Usually you're very good with
the default values to the route pattern.
You also have an host JSON file and
this is very important because this one is going to
talk to your serverless host and you have a local settings JSON,
which is a great file to use if you've got some local settings.
For example, to connect to various data sources and you end
up usually to push those to
the Cloud to your app settings for example,
you have a connection to a database
and you want to have a connection string,
local settings is a great place to put it.
Now you have the server.go,
which is our web app and if you're on Windows,
if you compile the server.go file,
you're going to end up with the server.exe.
But if you are on Linux,
that thing is just going to be called server.
I just want to emphasize
that you probably have a code file and you will
definitely need to have an executable and
that thing will be produced once you compile.
Server.go or server.exe.
Now, just to show you that
the difference between the two apps is not that big.
Here, you're looking at two pieces
of code from the same code file.
I just wanted to split it
up a bit so it's easier to see what's what.
If you look at first here we have our func main,
this is our entry point to any Go application.
One thing we need to know about a custom handlers and using Go in
serverless is that it reached towards a very specific port.
Instead of you entering port 3,000,
you go towards this environment variable that the host JSON knows
about and it's called FUNCTIONS_CUSTOMHANDLER_PORT.
That's all you need to remember,
you don't need to care about the port.
Azure functions will handle this for you via this parameter.
>> Okay.
>> The next thing to happen here is that you set up
the route and you can set that up into anything you want.
There's a thing with routes and HTTP that I
need to put an emphasis on and that is that
for web apps that only accepts
the HTTP trigger messages and only writes back HTTP messages,
you use something called port forwarding.
What this practically means for you as a developer is that,
if you've authored Azure functions before,
you know that you usually don't need to specify slash api,
you just specify slash products.
By me being very explicit here,
that means that I'm enabling
something called port forwarding and that
forces me as a developer to be very
explicit about what I want my full route to be.
This is something that's only true for HTTP apps.
It's not true for if you're dealing with
database triggers or queue message triggers.
This is really implementation detail,
but it does affect you as
a developer. I guess I want to mention that.
But I will show you that configuration,
so you're not going to be like a bot,
how do I configure port forwarding? I will show you.
This is just your HTTP server being up and running,
you're saying listen and serve towards in a certain port.
At this point, this is a one-to-one between
a web app and a serverless function app and Go.
Here we have our handler function.
The first thing we see is parameters,
we see a response stream that we can write
through and we see a request stream that we can read through.
This is when a user does a request,
they might fill in the body if they do not post,
or they might have something on
the URL in your browser where they input parameters.
What I'm doing here is first,
I'm setting the content type and when I set the content type,
this is for the client, so the client knows what type of
content is coming back so it's able to parse that code.
I set that to be JSON,
you can set that to be HTML text if you want to.
I just did this to show you how to deal with JSON.
This endpoint could potentially serve both a get and a post.
Here I have an if, that I say,
if you're get just send me "hello world" back.
But if you're type post or some other HTTP verb,
I'm going to attempt to actually read the body.
The body is a thing that,
for example, if you do web request,
you can send JSON or you can send texts or file,
whatever you want to put in there and then I end up writing
the body back to the user so they see that their post was okay.
This is a fairly simple code,
handle a get or handle a post depending what it is,
we end up returning different things.
All of this so I'm going to take a little poll there
from you Christopher and see how do you feel about it so far,
do you feel like you're still looking at a web app?
>> Generally speaking, yeah,
that it feels relatively natural to me
that I can see that normal setup down at the bottom,
bringing in the port variable and
then I'm telling it to go ahead and listen on that port,
pointing it at the handler and that handler does look
relatively familiar to me that I can
see how it is that I'm going to send information out
and how I'm going to read information and so yes,
it feels familiar to me.
>> Super. Do we have any questions
about this part or should I keep going?
>> The only little question that I have is just the the asterisk
that's next to http.request
so that mean that perimeter is optional?
>> The asterisk next to, sorry. What?
>> Next to http.request on the helloHandler parameter list?
>> Yeah, that one. I believe that means it's optional, yes.
>> Okay.
>> But you do need to I mean,
you don't have to read from the request of it.
>> Right.
>> You can actually just.
I mean, usually when you have a web request,
you tend to be interested in what's coming in,
either is on the URL or on the body.
I think that's a great question. Let move on.
>> Yeah.
>> I said that these two apps look the same way.
I said, or I think you confirm this
although reallocate still looks
like web app, but what's the difference?
The difference is the configuration files.
As part of those files that you get
when you first scaffold your app, you get the host JSON.
What it wants you to do is to add this portion in host JSON,
this is actually added for you if you
select a template that says custom handler.
It adds this entry in
that JSON file that's called custom handler and I want to put
your attention to this property because
you need to populate that this one ends up being
an empty string to start out with and this is
where they can find your executable application.
You remember a few slides back,
I said it's called server.exe.
In this case, I've taken it and I compiled it on
a Mac and at which case it's not called server.exe,
but it's rather called server.
What I do need to specify though is where do I find this?
If you want to put that executable file under a source directory,
you can do so, but you need to do is,
in that case,./.source.server.
It finds itself all the way to that executable file.
There's another property here because
for this time around we're dealing with
HTTP and I need to
enable this port forwarding for it to work properly.
Otherwise, it's not going to find my endpoint.
Once I enable this configuration,
that means that whatever route that I set up,
it needs to take you all the way from the route
which means slash api slash whatever your endpoint is called.
This is a HTTP only thing.
But you need to enable this too,
or it won't play well with web app.
Let's see here. Here we actually have
a little demo because I wanted to show you
all how this would work in real life.
Here we have a little prerecorded video that I have.
What you're looking at here is a scaffolded function
and it has host JSON local settings JSON,
it has this hello subdirectory.
This is a function endpoint and it has
a server because I can find this on a Mac.
It doesn't have a.exe ending and it has the server Go.
I want to show you how to run this function.
If you're looking at this now,
you can see that I'm running func start, which starts the app.
I get this annoying warning message.
You can just ignore it.
Once it's done, it's going to show you this is
the endpoint and once I click that endpoint,
you can see that it says, "hello world".
You can see that this works well.
We have api hello defined,
we are reading from this specific environment
variable and that's pretty much it.
By using the Azure functions core tools,
we're able to get our function up and
running and because this works,
because we have our executable server
with no.exe because I'm on a Mac
and we have set the configuration correctly so it knows how to
find an executable and that's pretty much it.
How to get your app up and running.