Architektura bezserwerowa - dwie usługi pod jednym punktem końcowym APIGW

Question

Jeśli mam dwie usługi: "Użytkownicy" i "Produkty", każdy z wieloma funkcjami z punktami końcowymi zdefiniowanymi dla każdego z nich (jak mógłby to zrobić każdy tradycyjny API), czy możliwe jest, aby być zorganizowane osobno w bazie kodu (dla jasności), ale po wdrożeniu mają ten sam podstawowy adres URL interfejsu API? Rozważmy na przykład mam następującą strukturę:

/src 
-- /users 
---- event.json 
---- handler.js 
---- serverless.yml 
-- /products 
---- event.json 
---- handler.js 
---- serverless.yml 

i mój src/users/serverless.yml ma następującą definicją:

functions: 
    create: 
    handler: handler.create 
    events: 
     - http: POST user 

    read: 
    handler: handler.read 
    events: 
     - http: GET user 

i mój src/products/serverless.yml w zasadzie to samo, tylko zamiana „użytkownik” do „produktów” .

Obecnie, zarówno tych usług zostaną wdrożone do wyraźnie różne punkty końcowe API, jeden z URL https://fghijklmnop.execute-api... a drugi z adresem URL https://abcdevwxyz.execute-api....

moje pytanie, to byłoby możliwe, aby usługi te są wdrażane, ale pozostają pod jednym interfejsem API z jednym adresem URL (aby oba były obsługiwane pod adresem URL https://abcdevwxyz.execute-api....)?

Zakładam, że odpowiedź brzmi: "Nie, ponieważ formacja chmurowa ...", ale pomyślałem, że zamieściłbym tutaj pytanie tylko po to, by porozmawiać i pomóc w zrozumieniu budowy aplikacji bezserwerowych.

Jestem świadomy używania niestandardowych domen, zgodnie z the answer here, ale dla szybszego cyklu rozwoju nie jest to idealne rozwiązanie.

Jedynym moim dotychczasowym rozwiązaniem byłoby po prostu utworzenie usługi o nazwie "api", która zawierałaby wszystkie punkty końcowe, których potrzebowałby mój interfejs API, które po prostu wywoływałyby bezpośrednio moje funkcje Lambda innych usług, a nie za pośrednictwem wcześniej skonfigurowanych punktów końcowych. Byłaby to naprawdę warstwa abstrakcji, ale dodaję potencjalnie niepotrzebne warstwy do mojej aplikacji. Znowu ciekawi, co społeczność na to czuje.

Answer 1

Wpadłem na własne rozwiązanie tego problemu. Wykreśliłem punkty integracji mojej aplikacji, aby mieć określone usługi integracji (API, S3, SNS itp.), Które reagują na zdarzenia, a następnie przetwarzają te zdarzenia i przekazują je do oddzielnych mikrousług. Napisałem na nim kod article z przykładami kodu.

Answer 2

można umieścić wiele funkcji w jednym serverless.yml

/src 
-- event.json 
-- users.handler.js 
-- products.handler.js 
-- serverless.yml 

Answer 3

nie mogę mówić bezpośrednio do wsparcia ramowej Serverless, ale z pewnością jest to możliwe w API Gateway.

Możesz przechowywać wiele plików Swagger dla każdego "sub API" i używać importu? Mode = merge do importowania obu definicji do tego samego interfejsu API.

Zobacz http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html

Dzięki Ryan

Answer 4

Można używać domeny niestandardowej nazwy: http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-custom-domains.html

konfiguracji nazwy domen niestandardowych (musisz certyfikat SSL) http://myapi.com/

następnie zmapuj swój apis:

http://myapi.com/users 
http://myapi.com/products 

Wystarczy zadzwonić swoje funkcje tak:

http://myapi.com/users/create 
http://myapi.com/users/read 
http://myapi.com/products/whaterver 

Answer 5

Co zrobiłem z mojego własnego kodu jest wyciągnąć cały kod spośród handler.js plików i umieścić go wewnątrz modułów.Moduły te będą wymagane w plikach handler.js, a następnie wywoływana będzie prosta funkcja.

usersModule.js:

export const doSomething =() => { 
    // Do something here. 
}; 

użytkowników/handler.js:

import {doSomething} from '../.../usersModule.js'; 

export const handler = (event, context, callback) => { 
    doSomething(); 
    // Do other stuff... 
    callback(null, "Success"); 
}; 

ten sposób można umieścić mięso kodzie gdzie chcesz go mieć, zorganizowany w cokolwiek sposób ma dla ciebie sens.

Użytkownik powinien jednak nadal mieć zdefiniowany pojedynczy interfejs API. Lub użyj odpowiedzi z RyanG-AWS, aby połączyć interfejsy API.

---

Jeśli nadal chcesz zachować definicje kod i API oddzielić można utworzyć API użytkownicy i produktów API osobno. Będziesz wtedy mieć inny połączony interfejs API, który wywoła którykolwiek z tych interfejsów API. W ten sposób otrzymasz pojedynczą usługę z jednym podstawowym adresem URL, do którego chcesz zadzwonić. Możesz to zrobić przy pomocy typu integracji HTTP. Nie próbowałem tego, więc nie wiem, jak dobrze by to działało.