aiir / pharrell Goto Github PK

Why end the serverless love at AWS Lambda?

See if there's a neat/simple way to introduce support for Cloud Functions too so a Pharrell based app can be portable across local server, AWS Lambda and Google Cloud Functions.

The prev/next pagination links in a list response are auto generated based on the size and position of the list results.

When a list result has 0 total results, the prev/next links will always be null, even if we request a page number outside the range.

Even with 0 results, we should enforce there being a single page of results and any out-of-range request should define a prev link to page 1.

As the core of Pharrell is essentially one piece of middleware and #1 is related to removing the unnecessary network-stack-to-feed-Lambda implementation, it may ultimately make more sense for Koa compose to merge the few bits together and map straight in to the Node.js HTTP stack directly via the listen method.

I'm not sure how much "magic" Koa is doing for us behind the scenes that make this too much effort. This will probably be clearer once attempting to remove the Lambda handler library for #1.

The body parser throws on invalid JSON and so gets caught and returned as an internal server error.

Invalid JSON should be treated as a 400 Bad Request error as per the Deliveroo API Design: "the entity cannot be created with the information in the request body".

Currently the Lambda handling is solely reliant on the AWS-supplied package that provides a wrapper around the Node.js HTTP library (running it via a socket) and melding the Lambda event and context callback methods in to it.

Whilst that works and provides a simple way to wrap up any Node.js HTTP/Express/Koa app, it might be nicer longer term to remove the dependency, avoid the internal network-stack-through-a-socket implementation and instead create a Koa-compatiable context object from the Lambda event, use koa-compose to create the middleware stack, and then feed the result back via the newly introduce Node 8.10 Lambda async handling.

A use case has come up where we wish to secure endpoints on the API.

Because the current approach of Pharrell abstracts endpoints away from any of usual request/response model of HTTP, we cannot implement this inside an endpoint method.

One way of introducing this would be to add the concept of both endpoints and the app adding middleware. These middlewares would need to be Koa-like (e.g. receive the context) to unlock the potential for doing clever things. In realistic terms, these would just hook in to Koa the same way the router does.

If, at point of mounting, the Endpoint was inspected and all possible options pre-compiled we could see further speed improvements. Should speed up handling of OPTIONS/Allows headers, too.

Because of the way the middleware layering is currently implemented, sending a malformed JSON body to a specific result throws an exception at the bodyParser middleware and gets caught and returned as an error with the generic key. Ideally, we'd only attempt parsing on the methods that allow JSON bodies and return a specific key.

Currently an endpoint has to support lookup, read and list functions to be mountable.

It's conceivable that an endpoint might be "write only" (e.g. not implement lookup, read or list), so this logic potentially causes issues.

The only real enforcement we should have at the mounting stage is that at least 1 supported function is implemented, so there's a point to having the endpoint mounted in the first place.

Another potential issue this highlights is that, by having a helper read function in the underlying Endpoint class, you can never not have a read function in your Endpoint subclass. A better approach would be to build this functionality in to the router so it can simulate the behaviour of a read method when only lookup is present.

The NPM package is missing several files.

When performing a request on an endpoint that hits a non-existent method, an error is thrown and an internal server error is returned to the user.

As the issue exists from the outset of the application, if we enforce the validation check as part of the mount function we could catch and exit earlier and avoid the potential of deploying an application with implementation errors on the endpoints.

For example, if list and create functions are not implemented, there is no need for the /resource route (without ID) to be present in the index.

create() has a requirement for (and generates an internal server error if) the returned object to include an id property so that the middleware can generate a _links object for the response with a self URL reference.

It is possible for a specific endpoint to not want this behaviour, particularly if it's doing something unusual which means no typical list() and read() responses. Whilst that can be handled by throwing forbidden or not found errors, the validation cannot be circumvented.

When endpoint methods are passed by reference through the router they become unbound from their own context, so later calls to this. within an endpoint fail.

Application middleware is currently being attached to the parent Koa instance, so runs before the router.

This means, for security middleware, you can receive a forbidden for a 404 route.

If all middleware execution is handled by the router, maintaining the relative order (app before endpoint) we could handle 404s ahead of executing middleware.

The Endpoint class' mount and use functions both return the Endpoint instance to allow easy method chaining.

It would be consistent to do the same with mount and use on App, too.