southpolesteve

I worked on IceCube. Was at the South Pole for a little over a month. Wild once in a lifetime experience. And if I am being honest I was terribly bored after the first 2 weeks. Its very flat and white and cold and not much to do. I was asked to go back the next year and I said no.

What an amazing accomplishment! I played a very tiny part in this project and went to the South Pole in 2009 to help with construction. Didn't see any neutrinos the entire time I was there though :/

I worked on this project in college and went to the South Pole in 2009. Happy to see it is still making discoveries!

Please do!

Azure Cosmos DB does. There is a good video about it: https://www.youtube.com/watch?v=kYX6UrY_ooA

I worked on this project in college and went down to the south pole after graduation to help install some of the detectors. Neat to see the results! ~10 years later.

Yes. bustle.com, romper.com, and elitedaily.com are all 100% serverless and do 80+ million unique visitors per month. GraphQL+AWS Lambda

More specifically React https://developer.microsoft.com/en-us/fabric

I also find `this` is terrible for linting. Most tools won't be able to figure you what you attached to `this` at runtime. It's a grab bag object ripe for bugs.

Very straightforward. We send text, they send back categories. We then map those to IAB categories in our own code

The mapping is custom. Not something they have out of the box.

I see this comment a lot. The issues are the same with any REST API. Often they have been solved many times by the community or are baked into whatever backend framework you happen to be using. GraphQL (and community) are still converging on a set of best practices, but you can still solve the issue yourself using the same techniques from REST. Here is how we do it at Bustle:

1. Wrap the entire query execution in an auth check. This is similar to whatever happens in a REST auth flow. Check the caller is legit before moving on. Nothing graphQL specific here.

2. Check auth on fields. This is a neat thing about graphQL. You can statically analyze the fields in the query to make sure the caller is only accessing fields they are supposed to. We do this by adding an `auth` property to the standard graphQL-js field object. When we build the schema we do some fanciness to wrap the resolvers in a new function that checks that field and behaves accordingly[1]

3. Throw errors on unauthorized data. Same as you would in a REST API. If you get back data the caller can't access, check it before replying. Obviously not ideal, but sometimes this is the only option.

At someone on twitter's request I wrote up some more thoughts a while back about running graphQL in production: https://gist.github.com/southpolesteve/08edb6a481c07f66eb71e...

I also gave a talk on this at Node Interactive last week: https://youtu.be/vI9ERvz9WWU

[1] https://gist.github.com/southpolesteve/e190e9572d060b5158366...

Yes. We use the Natural Language Understanding service at www.bustle.com for doing categorization of content. It maps decently to IAB categories: https://www.iab.com/guidelines/iab-quality-assurance-guideli...

Martin Fowler's serverless post was written by Mike Roberts. It is just hosted on Martin's blog.

The place you linked in Philly is a few blocks from my house. I've been a handful of times. Much more of a restaurant. I think it is a good example of a place trying to do too many things. As a coffee shop it is pretty sub par. It does not have a good vibe during the day. There are much better proper coffee shops within a few block radius.

Of course I am just one anecdote. They could be doing amazing.

We haven't seen any issues. Most of our latency critical functions are called a lot. We do get significant spikes in traffic but our CDN does handle some of that load.

API Gateway needs less config since they released the proxy style integration. In Lambda's case this means you can just return a JSON object like:

{ "statusCode": 200, headers: {}, body: "<h1>Hello!</h1>" }

And API Gateway knows exactly what to do. Before this, yes there was some extra config and it was not fun.

PS. Our AWS bill went down when we moved everything to Lambda but that was not the motivating factor for the switch

If you go to www.bustle.com or www.romper.com you get a JS app server side rendered by AWS Lambda and delivered through API Gateway (CDN in front of that). We do 50+ million unique visitors a month. Our team is super happy with the result and our AWS bill is smaller than it was on EC2. Cost was not a motivating factor for the switch but it is nice when the bill goes down.

It is most definitely ready. I gave a talk at Node Interactive last year that has some more detail https://www.youtube.com/watch?v=c4rvh_Iq6LE&index=2&list=PLf...

In graphQL they are called mutations http://graphql.org/graphql-js/mutations-and-input-types/

You are definitely not wrong. In our case the benefits have far outweighed the harshness from the bleeding edge. But for sure we have had to do a thing or two that I would rather not. Adding auth into graphQL, extending built in type classes are examples.

Reading the article, I come to the opposite conclusion. Of course I need GraphQL! I want these problems solved out of the box. I want to build on the shoulders of smart people who already solved them.

APIs are contracts. As a method of expressing those contracts, REST just doesn't have enough vocabulary and it is too simple. You have to make too many decisions on your own. That is where the "ful" comes from in RESTful :) Plenty of effort has been put into fixing this, but those tools never really received enough traction. They also fail to solve all the problems outlined in a single cohesive way. JSON-API is maybe the closest thing that currently exits.

Contrast that with GraphQL's explicit typed vocabulary. A more rigid and explicit language for API contracts. It is a godsend for writing complex APIs. Everything works out of the box. The developer friendliness also is fantastic (GraphiQL is the killer app). GraphQL places a high priority on developer and consumer UX which is something that previous iterations like SOAP and WSDL were lacking.

TLDR: GraphQL makes building complex JSON APIs easy. Sure you might not need it. But you probably want it.

Mostly it is not a big problem for us. Our functions that need to be fast have very high traffic. Our other functions don't need to be that fast. We also have a CDN in front of most things.

That said, we use node. I have heard cold starts are worse for Python (I have no data). I have heard they are near unbearable for Java (JVM startup and all that). We try and minimize external calls outside the main handler. Previous to this update we were packing configs with webpack at deploy time. Some people read them from S3 or dynamo. I don't consider that a good solution. I'll be working this week on Shep 3.0 which will use the new ENV var features.

I have talked to other people who do various hacks to force their functions to be warm. I've looked at doing this and haven't found it necessary yet for our use case.

We use Lambda and API gateway for all production[1] requests. HTML, Server side rendered JS, API calls. All through lambda. There are some rough edges. We wrote our own framework/deployment tool[2] to fix some of them. AWS has been making lots of improvements too. Many in just the last few months. This setup was much harder to run when we first started a year and a half ago. Overall our team is super happy. It is cheaper and simpler to operate than our previous ec2+Opsworks setup. We get code to production faster and spend more time on actual business problems vs infastructure problems. I also pretty much agree with everything Ben Kehoe said in this article: https://serverless.zone/serverless-vs-paas-and-docker-three-....

[1] www.bustle.com and www.romper.com do a combined XX million unique visitors per month.

[2] https://github.com/bustlelabs/shep

Thanks!

Congrats on the raise, but I'll be honest it really rubs me the wrong way that they renamed to "Serverless Framework" from JAWS. They should have picked a different name. The word "Serverless", for better or worse, was what the community settled on. Lot of companies and individuals use it in many different ways and have before this project existed. But they are trying to own it[1]. Not being a good community member IMO.

Edit: An example of the kind of thing I am concerned will happen[2]. Use the word "serverless" in a project? Get a take down notice.

[1]http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4802:t7t...

[2]https://twitter.com/sindresorhus/status/776142274564616192

I'm not sure why this myth persists. We've found Lambda + API Gateway to be an awesome solution for serving front end applications with server side rendering.

thanks for doing the math for me :)

Define horrific. The traffic that generates those calls also generates lots of revenue :) It is also extremely spikey. This is a big win for Lambda since we are only pay for what we need and don't have to worry about scaling EC2 up and down to meet demand.

I have one hard example I can share. We had a node service that was running on ec2 and cost ~$2500/mo. Moved the code directly over to lambda. Now ~$400/mo.

Quantifying other costs is a bit harder but do you have a DevOps person on your team? Or multiple people? How much do they get paid?

I can empathize with the OP. Using Lambda in production still has some pretty rough edges. You basically have to use one of the deployment tools/frameworks out there[1]. There are also just certain things it won't do (someone else mentioned binary data). Learning some of the limits takes time and it is not always super clear.

But my personal experience says Lambda is ready for prime time. We use it in production. ~15 million API calls per day. Mostly user facing HTTP requests. Even with the rough edges I would prefer to use it for any new web development project. It feels like at least an order of magnitude reduction in risk/complexity of scaling and deploying code. Its not "zero" but that is huge for me and for my team. We spend more time shipping.

[1]We wrote one: https://github.com/bustlelabs/shep but there are plenty of others mentioned in the comments.

For the case of Apex, I think "deployment tool" is better than framework. There isn't really any magic here. At least nothing you couldn't do yourself in the AWS console or UI. It would just suck for more than a few functions. This is automating all the clicking you would have to do otherwise and giving you a sane way to manage functions that can be grouped together.