aws-api-gateway & lambda: mehrere Endpunkt/Funktionen vs einzigen Endpunkt

Habe ich eine AWS-api-Proxys lamba-Funktionen. Ich verwende derzeit verschiedene Endgeräte mit separaten lambda-Funktionen:

api.com/getData --> getData
api.com/addData --> addData
api.com/signUp --> signUp

Den Prozess zur Verwaltung aller Endpunkte und Funktionen unhandlich. Gibt es irgendwelche Nachteile, wenn ich einen einzelnen Endpunkt, um eine lambda-Funktion, die entscheidet, was zu tun basiert auf der query-string?

api.com/exec&func=getData --> exec --> if(params.func === 'getData') { ... }

InformationsquelleAutor Chris | 2017-01-02

35

Es ist vollkommen gültig für die Abbildung mehrerer Methoden zu einem einheitlichen lambda-Funktionen und viele Menschen sind mit dieser Methodik, die heute im Gegensatz zum erstellen einer api-gateway-Ressourcen-und lambda-Funktion für jede diskrete Methode.

Könnten Sie die Proxyfunktion alle Anfragen auf eine einzige Funktion. Werfen Sie einen Blick auf die folgende Dokumentation über die Erstellung einer API-Gateway => Lambda-proxy-integration:
http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-set-up-simple-proxy.html

Ihrem Beispiel ist hier toll. Eine Anfrage wie die folgende:
```
POST /testStage/hello/world?name=me HTTP/1.1
Host: gy415nuibc.execute-api.us-east-1.amazonaws.com
Content-Type: application/json
headerName: headerValue

{
    "a": 1
}
```
Wird wind-up-senden Sie die folgende Ereignis-Daten auf Ihre AWS Lambda-Funktion:
```
{
  "message": "Hello me!",
  "input": {
    "resource": "/{proxy+}",
    "path": "/hello/world",
    "httpMethod": "POST",
    "headers": {
      "Accept": "*/*",
      "Accept-Encoding": "gzip, deflate",
      "cache-control": "no-cache",
      "CloudFront-Forwarded-Proto": "https",
      "CloudFront-Is-Desktop-Viewer": "true",
      "CloudFront-Is-Mobile-Viewer": "false",
      "CloudFront-Is-SmartTV-Viewer": "false",
      "CloudFront-Is-Tablet-Viewer": "false",
      "CloudFront-Viewer-Country": "US",
      "Content-Type": "application/json",
      "headerName": "headerValue",
      "Host": "gy415nuibc.execute-api.us-east-1.amazonaws.com",
      "Postman-Token": "9f583ef0-ed83-4a38-aef3-eb9ce3f7a57f",
      "User-Agent": "PostmanRuntime/2.4.5",
      "Via": "1.1 d98420743a69852491bbdea73f7680bd.cloudfront.net (CloudFront)",
      "X-Amz-Cf-Id": "pn-PWIJc6thYnZm5P0NMgOUglL1DYtl0gdeJky8tqsg8iS_sgsKD1A==",
      "X-Forwarded-For": "54.240.196.186, 54.182.214.83",
      "X-Forwarded-Port": "443",
      "X-Forwarded-Proto": "https"
    },
    "queryStringParameters": {
      "name": "me"
    },
    "pathParameters": {
      "proxy": "hello/world"
    },
    "stageVariables": {
      "stageVariableName": "stageVariableValue"
    },
    "requestContext": {
      "accountId": "12345678912",
      "resourceId": "roq9wj",
      "stage": "testStage",
      "requestId": "deef4878-7910-11e6-8f14-25afc3e9ae33",
      "identity": {
        "cognitoIdentityPoolId": null,
        "accountId": null,
        "cognitoIdentityId": null,
        "caller": null,
        "apiKey": null,
        "sourceIp": "192.168.196.186",
        "cognitoAuthenticationType": null,
        "cognitoAuthenticationProvider": null,
        "userArn": null,
        "userAgent": "PostmanRuntime/2.4.5",
        "user": null
      },
      "resourcePath": "/{proxy+}",
      "httpMethod": "POST",
      "apiId": "gy415nuibc"
    },
    "body": "{\r\n\t\"a\": 1\r\n}",
    "isBase64Encoded": false
  }
}
```
Jetzt haben Sie Zugriff auf alle Header, url, params, body etc. und Sie könnte verwenden, um die Anforderungen anders als in einem einzigen Lambda-Funktion (im Grunde die Umsetzung Ihrer eigenen routing).

Als eine Meinung, die ich einige Vorteile und Nachteile bei diesem Ansatz. Viele von Ihnen sind abhängig von Ihren spezifischen Anwendungsfall:
- Bereitstellung: wenn jede lambda-Funktion diskret ist, dann können Sie Sie einsetzen, unabhängig voneinander, die möglicherweise verringern das Risiko von code-änderungen (microservices-Strategie). Umgekehrt können Sie feststellen, dass Sie benötigen bereitstellen von Funktionen separat erhöht die Komplexität und ist beschwerlich.
- Selbst Beschreibung: API-Gateway die Schnittstelle ist extrem intuitiv zu sehen, das layout von Ihrem Erholsamen Endpunkte -- der Substantive und Verben sind alle auf einen Blick sichtbar. Die Umsetzung Ihrer eigenen routing kommen könnte, auf Kosten dieser Sichtbarkeit.
- Lambda-sizing und Grenzen: Wenn Sie proxy-alle-dann werden Sie wind-up benötigen, wählen Sie eine Instanz size, timeout etc. das wird Platz für alle Ihre Erholsamen Endpunkte. Wenn Sie diskrete Funktionen, dann können Sie sorgfältig wählen Sie die Speicher-footprint, timeout, deadletter Verhalten etc. am besten erfüllt die Bedürfnisse der speziellen Aufruf.
- Tolle Antwort. Der einzige Vorteil wäre die Sache für mich und dass ich nicht denke, ist: Lambda-sizing und Grenzen. Aber ich denke, die Vorteile überwiegen diesen Faktor. Könnte ich auch aufteilen in zwei Endpunkte catering verschiedene Arten von Anfragen. 1. Einfache DB-Abfragen mit beschränkter lambda-Ressourcen und 2. compute-heavy-Funktionen mit mehr leistungsfähige Ressourcen.
- Auf jeden Fall. Was ist schön in 2017 ist, dass Sie getroffen haben, alle uns zur Verfügung stehenden Möglichkeiten, so können wir wählen, den workflow, die am besten für unsere Bedürfnisse.
InformationsquelleAutor Dave Maple
12

habe ich seit 5~6 microservices mit Lambda-API-Gateway, und wurde durch mehrere try & Erfolg und Misserfolg.

kurz gesagt, aus meinen Erfahrungen, ist es besser, zu delegieren alle API-Aufrufe in lambda-Ausdruck mit nur einem APIGateway wildcard-mapping, wie
```
/api/{+proxy} -> Lambda
```
wenn Sie jemals irgendwelche frameworks wie Traube Sie wissen, dass, wenn Sie APIs, Funktionen wie

"middleware"

"Globale exception-handling"

"cascade-routing"

"überprüfung der parameter"

sind wirklich entscheidend.
als Ihre API wächst, ist es fast unmöglich, zu verwalten, um alle Strecken mit API-Gateway-mapping, noch ein API-Gateway unterstützt nicht diese Funktion auch.

weiter mehr, es ist nicht wirklich praktisch zu brechen lambda für die einzelnen Endpunkte für die Entwicklung oder Bereitstellung.

durch Ihr Beispiel,
```
api.com/getData --> getData  
api.com/addData --> addData  
api.com/signUp --> signUp  
```
stellen Sie sich vor Sie haben Daten ORM, Benutzer-Authentifizierung Logik, common view-Datei (z.B. Daten.erb).. dann, wie Sie gonna teilen, dass?

die Sie möglicherweise können brechen,
```
api/auth/{+proxy} -> AuthServiceLambda  
api/data/{+proxy} -> DataServiceLambda  
```
aber nicht wie "pro Endpunkt". möglicherweise können lookup-Konzept von microservice-und best-practice-darüber, wie Sie aufgeteilt werden kann der service

für diese web-framework wie Funktionen, Kasse diese wir haben gerade gebaut web-framework für die lambda, da brauchte ich diese in meinem Unternehmen.

InformationsquelleAutor Kurt Lee
7

Ich würde kommentiert haben, fügen Sie einfach ein paar Punkte zu Dave Ahorn s Super Antwort, aber ich habe nicht genug Ruf-Punkte, doch so werde ich hinzufügen, die Kommentare hier.

Begann ich, den Kopf nach unten den Pfad, der mehrere Endpunkte zeigt auf eine Lambda-Funktion, die behandeln könnte jeden Endpunkt unterschiedlich, indem Sie auf die 'Ressource' - Eigenschaft des Ereignisses. Nach dem Versuch es, ich habe Sie jetzt getrennt in separate Funktionen, die für die Gründe, die Dave vorgeschlagen plus:
- Ich finde es einfacher zu gehen, durch Protokolle und Monitore, wenn die Funktionen getrennt sind.
- Eine nuance, die als Anfänger wollte ich nicht aufnehmen, zuerst ist, dass Sie haben können, eine code-Basis, und zum bereitstellen des exakt gleichen code wie mehrere Lambda-Funktionen. Dies ermöglicht Ihnen, die Vorteile der Funktionstrennung und die Vorteile einer konsolidierten Ansatz in Ihrer code-Basis.
- Können Sie die AWS CLI zur Automatisierung von Aufgaben über die vielfältigen Funktionen zu reduzieren/beseitigen, die Kehrseite der Verwaltung verschiedene Funktionen. Ich habe zum Beispiel ein Skript, dass die updates 10 Funktionen mit dem gleichen code.
- Dies gilt nicht bieten eine Antwort auf die Frage. Sobald Sie ausreichend Ruf Sie werden in der Lage sein Kommentar auf jedem post; stattdessen Antworten, die nicht erfordern die Klärung von asker. - Nach Bewertung
- es ist eine perfekt gültige Antwort IMHO, und erfüllt die Anforderungen des OP (die ist über der Erwägung der vor-und Nachteile, nicht die eine konkrete Lösung).
- Ich denke, diese Antwort bezieht sich unmittelbar auf das, was der OP gefragt und ist absolut relevant. Ich war auch daran interessiert zu wissen, diese als Anfänger zu Lambda und jetzt ist mein Geist ist sehr klar!
InformationsquelleAutor John Wolf

Soweit ich weiß, AWS ermöglicht nur einen handler pro Lambda-Funktion. Das ist, warum ich erstellt habe, ein wenig "routing" - Mechanismus mit Java Generics (für stärkere Typ-überprüfungen zur compile-Zeit). Im folgenden Beispiel können Sie Aufruf mehrerer Methoden und an verschiedenen Objekt-Typen in den Lambda-und zurück über eine Lambda-handler:

Lambda-Klasse mit hf:

public class GenericLambda implements RequestHandler<LambdaRequest<?>, LambdaResponse<?>> {

@Override
public LambdaResponse<?> handleRequest(LambdaRequest<?> lambdaRequest, Context context) {

    switch (lambdaRequest.getMethod()) {
    case WARMUP:
        context.getLogger().log("Warmup");  
        LambdaResponse<String> lambdaResponseWarmup = new LambdaResponse<String>();
        lambdaResponseWarmup.setResponseStatus(LambdaResponse.ResponseStatus.IN_PROGRESS);
        return lambdaResponseWarmup;
    case CREATE:
        User user = (User)lambdaRequest.getData();
        context.getLogger().log("insert user with name: " + user.getName());  //insert user in db
        LambdaResponse<String> lambdaResponseCreate = new LambdaResponse<String>();
        lambdaResponseCreate.setResponseStatus(LambdaResponse.ResponseStatus.COMPLETE);
        return lambdaResponseCreate;
    case READ:
        context.getLogger().log("read user with id: " + (Integer)lambdaRequest.getData());
        user = new User(); //create user object for test, instead of read from db
        user.setName("name");
        LambdaResponse<User> lambdaResponseRead = new LambdaResponse<User>();
        lambdaResponseRead.setData(user);
        lambdaResponseRead.setResponseStatus(LambdaResponse.ResponseStatus.COMPLETE);
        return lambdaResponseRead;
    default:
        LambdaResponse<String> lambdaResponseIgnore = new LambdaResponse<String>();
        lambdaResponseIgnore.setResponseStatus(LambdaResponse.ResponseStatus.IGNORED);
        return lambdaResponseIgnore;    
    }
}
}

LambdaRequest Klasse:

public class LambdaRequest<T> {
private Method method;
private T data;
private int languageID; 

public static enum Method {
    WARMUP, CREATE, READ, UPDATE, DELETE 
}

public LambdaRequest(){
}

public Method getMethod() {
    return method;
}
public void setMethod(Method create) {
    this.method = create;
}
public T getData() {
    return data;
}
public void setData(T data) {
    this.data = data;
}
public int getLanguageID() {
    return languageID;
}
public void setLanguageID(int languageID) {
    this.languageID = languageID;
}
}

LambdaResponse Klasse:

public class LambdaResponse<T> {

private ResponseStatus responseStatus;
private T data;
private String errorMessage;

public LambdaResponse(){
}

public static enum ResponseStatus {
    IGNORED, IN_PROGRESS, COMPLETE, ERROR, COMPLETE_DUPLICATE
}

public ResponseStatus getResponseStatus() {
    return responseStatus;
}

public void setResponseStatus(ResponseStatus responseStatus) {
    this.responseStatus = responseStatus;
}

public T getData() {
    return data;
}

public void setData(T data) {
    this.data = data;
}

public String getErrorMessage() {
    return errorMessage;
}

public void setErrorMessage(String errorMessage) {
    this.errorMessage = errorMessage;
}

}

Beispiel POJO-Klasse User:

public class User {
private String name;

public User() {
}
public String getName() {
    return name;
}
public void setName(String name) {
    this.name = name;
}
}

JUnit-test Methode:

    @Test
public void GenericLambda() {
    GenericLambda handler = new GenericLambda();
    Context ctx = createContext();

    //test WARMUP
    LambdaRequest<String> lambdaRequestWarmup = new LambdaRequest<String>();
    lambdaRequestWarmup.setMethod(LambdaRequest.Method.WARMUP);
    LambdaResponse<String> lambdaResponseWarmup = (LambdaResponse<String>) handler.handleRequest(lambdaRequestWarmup, ctx);

    //test READ user
    LambdaRequest<Integer> lambdaRequestRead = new LambdaRequest<Integer>();
    lambdaRequestRead.setData(1); //db id
    lambdaRequestRead.setMethod(LambdaRequest.Method.READ);
    LambdaResponse<User> lambdaResponseRead = (LambdaResponse<User>) handler.handleRequest(lambdaRequestRead, ctx);
    }

ps.: wenn Sie deserialisation Probleme (LinkedTreeMap kann nicht umgewandelt werden ...) Sie in Lambda-Funktion (da uf die Generika/Gson), verwenden Sie die folgende Anweisung:

YourObject yourObject = (YourObject)convertLambdaRequestData2Object(lambdaRequest, YourObject.class);

Methode:

private <T> Object convertLambdaRequestData2Object(LambdaRequest<?> lambdaRequest, Class<T> clazz) {

    Gson gson = new Gson();
    String json = gson.toJson(lambdaRequest.getData());
    return gson.fromJson(json, clazz);
}

InformationsquelleAutor Jörg

0

So wie ich das sehe, Auswahl single vs multiple-API ist eine Funktion von folgenden überlegungen:
1. Sicherheit: ich denke, das ist die größte Herausforderung, mit einer einzigen API-Struktur. Kann es möglich sein, verschiedene security-Profil für die verschiedenen Teile der Anforderung
2. Denke microservice-Modell aus der business-Perspektive:
  Der ganze Zweck einer API dienen sollten, einige Anfragen, daher muss es gut verstanden und leicht zu bedienen. So Verwandte APIs kombiniert werden sollten. Zum Beispiel, wenn Sie ein mobile-client, und es braucht 10 Dinge gezogen zu werden, in und aus der DB, macht es Sinn, um 10 endpoints in einer einzigen API.
  Aber dies sollte sich in Grund und sollte gesehen werden, die in Zusammenhang mit der Allgemeinen Lösung-design. Zum Beispiel, wenn Sie entwerfen eine Lohn-und Gehaltsabrechnung Produkt können Sie denken, separate Module für leave-management-und Benutzer-Informationen management. Auch wenn Sie oft von einem einzigen client, sollten Sie noch andere API, weil Ihre wirtschaftliche Bedeutung ist anders.
3. Wiederverwendbarkeit: Gilt sowohl für code und Funktionalität Wiederverwendbarkeit. Code-Wiederverwendung ist ein problem einfacher zu lösen, dh build-common-Module, die für gemeinsame Anforderungen und bauen Sie als Bibliotheken.
  Funktionalität Wiederverwendbarkeit ist schwieriger zu lösen. In meinem Kopf, die meisten von die Fälle können gelöst werden, durch Neugestaltung der Wege-endpoints/Funktionen niedergelegt, weil, wenn Sie benötigen, Duplizierung von Funktionalität, dass heißt, Ihre erste design ist nicht detailliert genug.
Fand gerade eine link in dem anderen Beitrag, der fasst besser

InformationsquelleAutor Ayan Guha

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.