creztoe

That sounds awesome and also a huge headache. I've found its much easier to work with an ORM that is specifically designed for GraphQL, like TypeORM[1]. Otherwise you are just kind of trying to force a square peg in round hole (like Graphene[2] for Django). As for not exposing some data, just use "private" schema directives, etc.

[1] https://github.com/typeorm/typeorm [2] https://github.com/graphql-python/graphene

That's how I understand it. Basically you have a machine hosted somewhere with a dedicated IP so you can access all remote machines from anywhere at any time, as long as they are connected to it via reverse proxy.

Do not pass sensitive data to docker build via --build-arg. When you access this with "ARG" you will log the information in the docker history, visible to all. Use "--secret" or use the ARG in an intermediate build stage which doesn't have it's history preserved, then copy any necessary files form the intermediate image to your file image manually.

A perfect example of this would be passing your NPM_TOKEN to install company scope packages.

This kind of confuses me a bit. Why would you want to turn Pub/Sub into a queue?

How badly does this affect message acknowledgment and retries? I assume just a huge hit to latency. This seems like a horrible idea for anyone expecting to use multiple subscribers or expecting to chunk multiple messages per request.

Services relying on Pub/Sub should be idempotent anyway. If you need to work around that for some reason, you are better off dumping messages from your subscriber into RabbotMQ or Redis for processing and use a Subscriber/Scheduler/Worker pattern.

Maybe it's just me, but I didn't get that from rozab's comment at all. I figured the point was something like, "Why is this project unique? Maybe the time would have been better spent contributing to an established project that has already accomplished these basic features." Which seems like an honest question.

This seems like it's just a click-baity ad for their productivity analysis tools. I struggle to find a single thing of value in this post.

I'm lazy. I've found a gitlab wiki sufficient for my basic needs. 1. Version control 2. Easily editable from terminal (markdown) 3. Easily viewed via browser (either on gitlab or self hosted gollum instance) 4. Supports some HTML, such as `details` and `summary` for drop down visibility. 5. Supports `[[_TOC_]]` to add a table of contents (works well with in `details` at the top of every page) 6. Supports nested directories for the sidebar navigation on gitlab (github forces a single layer)

Could you explain why helm is garbage? I think it suits its purpose rather well without being too complex. You can essentially "plug-in" different types of resources rather easily. Especially in v3 now that you don't need to install Tiller and can avoid setting those cluster permission requirements.

Have you tried some Kubernetes api libraries? You can generate and configure resources with [python kubernetes-client](https://github.com/kubernetes-client/python) without much trouble. Personally I prefer editing them as JSON instead of python objects, but it isn't too bad.

Yeah, I was referring to the certbot warning of "logging" the IP publicly. But I guess that policy never actually came to fruition. Thanks for the clarification!

I think you are half correct. The gateway has nothing to do with verifying the file during a DNS challenge. However, the IP of the machine requesting the cert IS saved with that cert information and made public. Let's encrypt will even warn you during the verification process.

I agree with the confusion. There is the ability to rollout updates in a "wave"[1], but I'm not sure how this is better than a simple rollout strategy in kubernetes since a reboot of the node seems inevitable.

[1] https://github.com/bottlerocket-os/bottlerocket/tree/develop...