I have a GBD-200. battery life is like 2 years lol. the notifications aren't the most reliable... sometimes it disconnects and I'm not sure why.
245 karma · joined July 29, 2014
There's some small quirks to iron out but overall, great product, super great price.
I have now lost faith in you, GCP.
I'm in the same boat as you, tho. I'm in the video game streaming industry... I don't understand at all how people actually watch other people play video games, and I do think there's benefit to disconnect.
Signed and donated. It happens to me every, single, fucking, time, losing 1 hour every trip back home.
For bigquery, we wrote this nifty tool https://github.com/SplitmediaLabsLimited/supermigration
Each member of your team can do it, and it works retroactively.
They both have regions. One makes it easier to see at a glance.
They both have the concept of reserved IP, one doesn't need to be set first.
They both install ssh keys for you. One does it per user, the other per instance.
One sets up cross region VPC for you. The other one makes you suffer and do it yourself.
In GCP, I can easily create networks between projects. It's really shitty to do in aws.
In GCP, I can create a machine and everyone in my team automatically has ssh access.
In GCP, I can make an instance, then mark the IP as reserved. In aws, I have to reserve the IP first.
Aws UX is the worst. I use both on an everyday basis. I could go on and on..
/graphql/{queryname}/{hash}?{params}
Multiple advantages:
1) client doesn't need to send the whole query unless it doesn't exist. All of this is handled automatically.
2) http caching of queries are now possible since it's a get instead of post
3) we can check slow queries using similar tools as rest. When we see a query being slow, we check each resolvers. We usually keep the queries simple
Filipino uses a system called tabo, or sometimes a hand hose bidet (I call it the bum gun). If the pressure of bum gun is strong enough, well, it's like a pressure gun. You shoot it at 45 degrees angle (cause 90 hurts lol).
If the pressure is not strong enough, then use it like tabo. Tabo is a water scoop. You water your hand, you water your butt, then you soap both of them, and wash it out. It's a shower but just for your butt.
This sounds a little bit weird and disgusting but it is the cleanest since it's like a shower. Nothing beats a soap and scrub.
If there's tissues, take a tissue, pat down your butt so it's dry, put it in the bin.
Hope that explains it!
Thank you for doing this.
1) We moved from Gitlab to Phabricator and Phabricator CI sucks so much, we integrated buildkite with it instead
2) We quickly realised that Buildkite UI is superior, but also its runners. You can add custom extensions to Buildkite and make it do whatever you want https://buildkite.com/plugins
We use service owners, so when a change spans multiple services, they are all added automatically as blocking reviewers.
They're equivalent in the sense that you have nodes that can die anytime, but it's much more complicated. You could technically have a much lower cost on AWS by aggressively bidding low but we've had a few instances where the node only lived a few minutes.
Preemptibles nodes are max 24h, and from our stats, they really live around that amount of time. I think the lowest we've had was a node dying after 22h.
You also save out of the box because they apply discount when your instance is running for a certain number of hours.
You can even have more discount by agreeing to a committed use which you pay per month instead of one-shot unlike AWS.
I'm going to add a few more reasons to the above reply:
- UI and CLI is so much better in GCP
I don't have to switch between 20 regions to see my instances/resources. From one screen, I can see them all and filter however I like.
- GCP encourage creating different projects and apply same billing.
It's doable in AWS too, of course, but coupled with the fact that you have different projects and regions, and you can't see all instances of a project at once, this makes a super bad experience
- Networks are so much better in GCP
Out of the box, your regions are connected and have their own CIDR. Doing that in AWS is complicated.
- BigQuery integration is really good
A lot of logs and analytics can be exported to BigQuery, such as billings, or storage access. Coupled with Data Studio and you have non technical people doing dashboards.
- Kubernetes inside GCP is a lot better than AWS'
https://blog.hasura.io/gke-vs-aks-vs-eks-411f080640dc
- Firewall rules > EC2 Security Group
- A lot of small quality of life that makes the experience a lot better overall
... like automatically managing SSH keys for instances, instead of having a master ssh key and sharing that.
Here's the thing though, a lot of GCP can be replicated, just like what you linked for the identity provider. With GCP, there's a lot of stuff out of the box -- so dev and ops can focus on the important stuff.
Overall, AWS is just a confusing mess and offers a very bad UX. Moving to GCP was the best move we've made.
Just make sure your app has proper probes, and make sure the probes returns 500 when the process receives a sigterm, and it should be invisible to you.
We listen to the cloud pubsub from a worker.
1) we don't manage it. We receive quite a lot of webhooks and it's nice to offload that 2) all of our webhooks are async. We just have 1 worker that handles it all, instead of provisioning a bunch of pods. 3) managing cloud functions is dope, since you can make it autodeploy from git.
10/10 would use again. Not sure about building a whole app around it tho
Honestly, it was a pain, but it's because we abused Redux.
We progressed by doing the HOC and bypassing Redux but it still was a pain, because HOC.
We're now at a stage where we updated Apollo versions, and started converting to the Query components. It feels and work a lot better.
When we started, we thought the same thing -- keeping data fetching separate from the view layer if possible. We realised that it didn't make that much sense. Keeping everything in React components is a lot more maintainable and easier to comprehend.
Our implementation is a little bit naive - it doesn't "clean out" or see which resources are being used.
On the frontend:
There's a script that globs all `.graphql` files and compiles them into a list of {query, variables}. This probably could be made better if it was a webpack plugin that compiles this on build time. This was a Friday project so our time was pretty limited. This was honestly good enough since it caught a shitload of bad queries =).
Query contains the graphql query. Variables contains test arguments.
It saves them into a gigantic file (example: https://gist.github.com/maktouch/074339517a8da5128d62869356b...)
On the GQL server:
We take that file, we parse it, and we loop it and pass it thru the validate function (https://graphql.org/graphql-js/validation/#validate)
(truncated example: https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361...)
Ops:
Frontend and GraphQL are its own Docker image. We build both in parallel. When both succeeds (in building and running their own tests), there's an extra build step that runs this specific test. It does it by taking the gql-queries.json file from the frontend container, adding it to the GraphQL image, and running the validate command.
You can do this by doing multi-stage builds in Docker (https://docs.docker.com/develop/develop-images/multistage-bu...). We don't push the resulting image - it's just there for testing.
You are right - GraphQL, even though it has the word "graph" in it, is pretty weak at complex graph traversal. Actually, I don't think it was made for complex graph traversal in mind.
https://docs.dgraph.io/master/query-language/ uses graphql, but they really modified the language to make it work for complex graph traversal, to a point where the simplicity of it is gone.
In our current service, I think we're pretty happy with the way our structure is. It's almost similar to saturn-gql but with raw javascript instead of parsing with `graphql-tools`.
The standard is made to be extended (https://www.apollographql.com/docs/graphql-tools/scalars.htm...)
For example, you should start with making your own DateTime scalar.
> What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database.
You can totally do this without raw json scalar. Actually, it would be better without it.
If you could go more in-depth details, I could make you a PoC.
I hope this book will cover some topics for others that was real head scratchers for us
- DataLoaders
- Authentication example
- Unions and Interfaces are your friend. Use them early.
- Try to define your custom Scalars early (especially DateTime format)
- return Connections (edge/node) instead of List cause you probably want to paginate at some point
- Folder structure (we redid ours 4 times lol)
- Naming convention (we redid ours 3 times lol)
- Subscriptions
After 2 years of using it and hacking it, we're still impressed. Once you get past the learning curves and have set conventions, writing GraphQL is a lot faster and better. Define your types, and some custom root queries, and done.
The neatest thing is that we made a schema validator -- compile all the graphql queries from the frontend and mobile, and validate them against the server schema. It really help when we changed folder structure and naming convention to see if we'd break something on the frontend.
I can't vouch for this book yet, but I'll swear my life on GQL. It's been a real game-changer.
> I don't see how I can implement complex object hierarchies that are not rigid.
I'm not sure I understand what you're trying to do, but did you try the JSON scalar type? https://github.com/taion/graphql-type-json
With that, it just returns JSON but you can't pick and choose what keys gets returned.
We never had to use that though. We prefer to use interfaces or unions.