So first of all, we're going to look
at why to reuse this functionality?
Is it's something that we just do as devs?
But do we really think about why we do that?
It's not just a hack, it quickly,
sometimes, and just be able to hack
stuff out quicker than next time.
There's reasons for it.
There's backups, and there's
reasons why we do what we do.
How do we handle not just
little bits of functionality,
but what about these big process is?
What if their quote engines?
Well, if there I don't know we gotta
spin through millions of records,
pull loads of different APIs,
how do we handle
All that sort of thing in a sensible way?
Then furthermore,
how do we actually bring
that to the power platform?
How do we tie these two things together?
These Azure functions,
these reusable bits of code?
How do we bring that to
life in the power platform?
How do we help everyone in our
organization achieve more with that?
Firstly,
we're going to look at how we do that
with the back end of the power platform,
so the common data service,
and then how do we empower the apps
themselves to use these functions?
And how do we
move that on so that our UX,
our user experience is just much,
much better than it has been?
And how do we get that out
the door in the best, most efficient way?
So to dig into those bits
just a little bit further,
why do we reuse the functionality?
Yes, shorter development times.
One of the things we think
about if we've if we've spun up
some code for building an app,
then the shorter development time is great,
because when we spin up app #2,
we haven't got to build that
bit of functionality again.
If we think about,
I don't know just a small piece
of validation that we could
put in an Azure function,
let's say validating
a UK phone number so we give it
the country code of say that +44
at the start and then if it's a
mobile number will have 07 at the
start and will drop the zero.
That kind of leads on to the
next point of the consistency.
Even within that tiny tiny little
scenario there's loads of little
nuances of things that could go wrong.
Things that could be different
here there or the other.
We don't want our web app over here,
our internal canvas app over there and
our portal for our customers to be
different.
We don't want the experience to
be different in all those places.
Think about the mobile app as well,
customer shouldn't go to the
website and the mobile app and get
a different experience on even the
smallest of things like managing
a phone number validation. That
also helps with the clean data and
keeping everything good right?
Clean data is good data.
We can then push that back
through to our Power BI
were talking about something
a bit more than phone numbers and
we're in a better place for the
future to be able to take that on.
Easier testing, now this
probably is taken as a given,
but again, just with that small
example of the phone number,
there's loads a little scenarios if
we're talking about automated tests,
it takes awhile to write those to
give it all the different scenarios
to make sure we're in a good place to
push out good quality, secure code.
If we're talking manual tests
that can take ages to get through
all of these different scenarios.
So let's think about the reuse
from that point of view.
Let's just,
once we've got this thing set up
and spun up in production once,
then every time we test a new app.
So I'm building at two and
building mobile app three.
I'm building website #4, every little
bit there all I need to do is check
I'm connecting to my Azure function.
The rest of what the function
does already covered out the way.
And I guess point #4 on here
something we almost take for
granted sometimes specifically is
devs. The life proven code exactly
what we were just talking about.
If we have app one that's been deployed,
it's been sat in production being used
within our mobile app for six months.
A year where we then know that we
don't really have to think about
that little bit of functionality
or that bit of functionality.
That bit of functionality it's already
in production, is already proven.
We know that's going to scale up
and scale down as we need. When
we are pushing out App 5,
we just know that we the rest of the
business is much more comfortable that
all of these separate bits of functionality
are all there.
They're all out there all working.
It's just this one core bit this going
out which gives us a lot more buy in
from the business to be able to to
get more out and get it out quicker.
So I think we just we speed everyone
up this way and all possible parts of
that development and app lifecycle.
So that's a bit about why we
reuse the functionality.
Now,
how do we tie that in
with the power platform?
How do we bring this?
No code, low code platform and the scale
and the awesomeness of Azure together?
And how do we
How do we bridge the gap?
There's no cliffs between the two,
but how do we actually tie them together?
And the main one that we've kind
of heard about with a great talk on
serverless before this one of the
main parts of servers that we see
most commonly used on the platform
is Azurey functions.
So as your functions, if
anyone is not aware,
I'll just ways of bringing our fairly
small, succinct pieces of code and
sitting down with our different
business events and our data.
I'm just to have our triggers there
an to piece those things together.
Sorry I gotta run that that animation again.
That's just too good. That right.
Whoever built that originally
needs some credit there.
But the Azure function,
so we're mostly going to be
talking about is your functions
triggered by HTTP request in this
in this took some work into an API,
but we can have all sorts
of things trigger functions,
whether it's service bus topics,
messages,
or whether we're binding to Cosmos
DB and the same with outputs as well,
we have the whole authentication
if we if if we need
different types of authentication.
Here we consider behind Azure API
management for for making making
things secure and splitting things
apart and separate and our concerns.
And we can also write them
in multiple languages.
We're going to look at C sharp
example in a second, but.
We can write in JavaScript,
TypeScript all sorts of different
languages that are available for us now.
We also have the advantage of scaleability's.
The main thing that one of the main
things that comes out of serverless,
this thing is going to scale up to
phenomenal levels and back down again,
as in when we need it without us doing
a thing which is, which is great.