southpolesteve
Joined 16 years ago
Karma
831
Submissions
160
Member since
Oct 19
Recent submissions
Comment · 1 month ago
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.
Comment · 1 month ago
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 :/
Comment · 2 years ago
I worked on this project in college and went to the South Pole in 2009. Happy to see it is still making discoveries!
Comment · 6 years ago
Please do!
Comment · 7 years ago
Azure Cosmos DB does. There is a good video about it: https://www.youtube.com/watch?v=kYX6UrY_ooA
Comment · 8 years ago
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.
Comment · 8 years ago
Yes. bustle.com, romper.com, and elitedaily.com are all 100% serverless and do 80+ million unique visitors per month. GraphQL+AWS Lambda
Comment · 8 years ago
More specifically React https://developer.microsoft.com/en-us/fabric
Comment · 9 years ago
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.
Comment · 9 years ago
Very straightforward. We send text, they send back categories. We then map those to IAB categories in our own code
Comment · 9 years ago
The mapping is custom. Not something they have out of the box.
Comment · 9 years ago
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...