O jednej rzeczy nie wspomniałem (lub może nie dałem na nią nacisku) w zeszłym tygodniu i chcę to tutaj zaznaczyć. Tydzień temu pisząc o AWS Lambda skorzystaliśmy z szablonu Lambda Empty Function, który jedynie zamieniał podany ciąg znaków na duże litery.

Funkcja która to wykonywała wyglądała mniej więcej tak:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;

using Amazon.Lambda.Core;
using Amazon.Lambda.Serialization;

[assembly: LambdaSerializerAttribute(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]

namespace t1
{
    public class Function
    {
        public string FunctionHandler(string input, ILambdaContext context)
        {
            return input?.ToUpper();
        }
    }
}

Trzeba tutaj zaznaczyć kilka bardzo ważnych rzeczy:

  • Klasa nie musi być tak nazwana
  • Handler nie musi być tak nazwany
  • Handler nie musi zwracać string i przyjmować string (input)

Tak naprawdę możemy zmienić:

  • Nazwę klasy
  • Nazwę funkcji
  • To czy funkcja jest statyczna czy nie
  • To czy funkcja jest async czy nie
  • To jakiego typu jest parametr input

To co jest ważne to:

  • Kolejność parametrów (najpierw input, a potem ILambdaContext)

Jak widzicie szablon, który użyliśmy jest po prostu jakimś spojrzeniem na to co możemy zrobić. Równie dobrze, sami możemy to napisać nie korzystając w ogóle z szablonów. Oczywiście, więcej będzie pracy (ciutkę), ale jest to wykonalne.

To co jest bardzo ważne, to przy deployowaniu naszej funkcji musimy podać nazwę naszej funkcji. Jak pamiętacie, przy tworzeniu szablonu był sobie plik aws-lambda-tools-defaults.json. W nim zaś własność:

"function-handler" : "t1::t1.Function::FunctionHandler"

Co to takiego? A to właśnie jest powiedzenie AWS jaka funkcja stanowi handler, ma to schemat:

Assembly::Type::FunctionName

To dzięki temu AWS wie jaką funkcje wywołać z naszej aplikacji. Jak potworzycie sobie różne rodzaje szablonów które są dostępne to zobaczycie, że patent z function-handler się zawsze powtarza. Zmienia się pierwszy parametr i zwracana wartość, ale schemat jest ten sam. To czym różnią się te schematy to po prostu paczkami nuget plus przykładowym kodem.

W sensie, nie ma nic bardziej skomplikowanego w tym, że korzystamy z Simple DinamoDB Functon a Empty Function. Są jednak wyjątki takie jak szablon ASP.NET Core Web API (gdzie tej funkcji w sposób jawny nie musimy pisać), który umożliwia nam uwaga, uwaga, hostowanie Web API jako FaaS. Ciekawe rozwiązanie, bardzo ciekawe.

Warto to tutaj zaznaczyć, że opcje deploy-function itp. są niezależne od szablonu i są one dostarczone przez zupełnie inną paczkę Amazon.Lambda.Tools o której wspominałem tydzień temu.

Jako, że nie zajmujemy się tutaj SDK Amazona, pominę większość szablonów, ale opiszę na pewno ASP .NET Core Web API szablon i jak to jest możliwe, żeby hostować Web API jako FaaS.

Czyli plany na kolejne tygodnie są już dość jasne, wszystko zależy od czasu jaki będę mógł na to wszystko poświęcić. A im więcej czytam tym więcej chce się pokazać :) Może pod koniec jakiś cage match pomiędzy dostępnymi rozwiązaniami implementujący tę samą aplikację. Myślę. Pomysły? :)

PODOBNE ARTYKUŁYWIĘCEJ OD AUTORA