Pre-rendered Responses about serverless HOT 19 CLOSED

Lava iris

from serverless.

I came to the same conclusion as you.

Until Amazon extends the capabilities of API Gateway this is impossible, like you said.

from serverless.

It actually looks like it would be possible to return an html response from the API gateway, so this might be possible already.

from serverless.

@devknoll Where do you see this?

from serverless.

@ac360 https://forums.aws.amazon.com/message.jspa?messageID=650072#650072 This + a couple other posts imply that non-JSON requests/responses are possible. Should just be a matter of setting up a text/html response, but I haven't tried it.

from serverless.

It's definitely possible. I wrote a blog post about it: https://medium.com/@devknoll/rendering-react-with-amazon-lambda-e4e85a788257

from serverless.

@devknoll you are the man. When I tried I got stuck on the mapping template and could only ever get json back.

@ac360 can we reopen this one?

Thanks a ton for taking the time to write down your methods.

Like you said in your post, the problem now is figuring out how to route traffic from route 53 to api gateway directly.

From the AWS Route 53 readme

"If you're using Amazon CloudFront, Amazon S3, or Elastic Load Balancing, you can configure Amazon Route 53 to route Internet traffic to those resources. There's no charge for the DNS queries that Amazon Route 53 routes to CloudFront, Amazon S3, or Elastic Load Balancing. For information about routing queries to a variety of AWS resources, including Amazon EC2 instances, Amazon RDS databases, and Amazon WorkMail, see Routing Queries to AWS Resources."

The way I see it things would have to work like this.

Route 53 -> CloudFront -> API Gateway -> Lambda

CloudFront seems necessary both from a security perspective, and because there is no api for sending r53 traffic directly to api gateway.

from serverless.

API Gateway has an option for setting up Domain Names for an API. Is there another reason you're using Route 53?

from serverless.

You could also shortcut having to make an entry for each possible route by using resources and just making a GET/POST method for /{resourceName} up to the desired depth, just ignoring it, and pulling in the full path to pass along to your router.

from serverless.

@devknoll you are absolutely right, my understanding of API gateways capabilities was wrong.

To anyone else that may be interested here is the relevent link to the api gateway docs for setting up a custom domain.

Also, here is a guide to generating a self signed cert that will work for api gateway custom domains.

My biggest concern was that you would no be able to leverage cloudfront by directly exposing the api surface.

However:

"API Gateway is not currently integrated with domain name registrars or managed DNS providers. You must register your custom domain name with a domain name registrar before setting it up in API Gateway. After you’ve set up your domain name and base path mapping(s) in the Amazon API Gateway console, you must update your domain name with your authoritative DNS name server provider to direct traffic to the CloudFront distribution API Gateway created for your domain name. The domain name of this CloudFront distribution is displayed as the “Distribution Domain Name” in the Amazon API Gateway console."

It seems like api gateway automatically sets up a cloudfront distribution, awesome.

from serverless.

@devknoll have you noticed that redeploying the lambda breaks the api created in the method you described? If you delete the method and recreate it using the same method then everything works again.

from serverless.

No, I haven't done much else with it yet since getting the proof of concept running.

I'm a little worried about using something like this in production at the moment, given the range of response times I'm seeing. Warm starts seem to be around ~130ms, while cold starts can be up to 1.3 seconds. Include any APIs that are cold as well, with any initialization they need to do (e.g. connect to a DB or cache) and you're probably looking at at least 2 seconds before the first byte is delivered...

I'd love to see your progress or your own metrics though!

from serverless.

So here is my progress on this so far.

Create react page component for ssr lambda

var React = require('react');

var RootComponent = React.createClass({
  render: function () {
    return (
      React.createElement("html", null,
        React.createElement("head", null,
          React.createElement("title", null, this.props.title)
        ),
        React.createElement("body", null,
          React.createElement("img", {src: this.props.imgSrc})
        )
      )
    )
  }
});

RootFactory = React.createFactory(RootComponent);

exports.handler = function(event, context) {
  var root = RootFactory({
    title: 'test-title',
    imgSrc: 'https://raw.githubusercontent.com/jaws-stack/JAWS-graphics/master/jaws_logo_javascript_aws.png'
  });
  context.succeed(React.renderToStaticMarkup(root));
};

Local output via jaws-run, notice that none of the quotes are escaped

Deploy Lambda, and test, notice quotes are now escaped

Configure api, and test get request, quotes are still escaped

Deploy api and test endpoint in browser

Escaped and quoted string is sent as response

Conclusion

I'm not sure why Lambda seems to be auto escaping and quoting the response string, which causes problems when delivering the html, the browser interprets it as a string instead of markup.

Here is a the code if you would like to replicate

from serverless.

@devknoll Did you check out the Optimization Guide? There are some good tips in there. Increasing the Lambda MemorySize is a big one. I'm not sure what you mean about "APIs being cold". Do you mean you are seeing that API Gateway also has cold-start issues, aside from Lambda and other services?

Overall, the lambda cold-start issue is a serious problem for JAWS and AWS. I'm talking to the AWS Lambda team tomorrow and I will bring up the cold-start issue and attempt to get optimization tips from them. Everything I find out will be added to the Optimization Guide.

from serverless.

I created issue #39 and pull #40 that fixes the inconsistencies I was seeing between the local jaws run and my results on aws.

However it is a problem that the results of every lambda are JSON.strigified, it is going to make returning markup problematic :/

from serverless.

@austinrivas This happens when the mapping template isn't set up correctly. I just tested and can confirm that the resulting text isn't escaped. Make sure it's $input.path('$') for each of your HTML methods. The output from the lambda directly will always be escaped, though.

@ac360 Excited to hear the results of your chat.

In general, what I mean is:

• Hit cold react rendering lambda: +1 second
• React rendering lambda hits cold API lambda: +1*n seconds (depending on the shape of your request tree)

I haven't tried adjusting the memory size yet. I wonder if any cold start improvements with it could be attributable to a relative lower number of users with higher memory sizes, leading to functions being cached longer...

In general, I'd love to be able to pay a little extra to have a guaranteed cold start time, just to be able to develop in a JAWS-like paradigm.

from serverless.

Strange, I didn't notice any drastic improvements with higher memory usage through API Gateway. The lambda itself, through the test interface, seems to execute faster, but cold start times through API Gateway are still ~1 second or greater, even at 1536mb.

from serverless.

@devknoll I had a conversation with the Lambda team today. I brought up this issue because it is critical for their success and the success of JAWS. We discussed it for ~20 mins and I learned a lot. Tonight, I tried to add some further clarity on this issue and optimization tips in the JAWS Optimization page. Perhaps something in there can help you.

Most importantly, the AWS Lambda team is well aware of this and they are working on several strategies to improve this issue. They even mentioned that we should see improved Lambda start-up performance within 2 weeks.

As for now, I will continue to make JAWS-Lambda support as optimized as possible. If you stumble across anything in particular that helps. PLEASE let me know!!!

from serverless.

I'm a big dumb.

pasting $input.path(‘$’) from the blog post was breaking the aws mapping template. ' from medium are dangerous.

That's what I get for being lazy. Everything is working as expected now and I think we can safely close this one @ac360, unless you want to keep it open for conversations sake.

from serverless.