quantdaddy
Joined 9 years ago
Karma
20
Submissions
12
Member since
Oct 2
Recent submissions
Comment · 4 years ago
Deploying a blog is so easy and there are a myriad of tools. However, they are just tools: self managed or not. They do not bring the audience to you. The goal of Truegit is to bring the social components (WIP) to your blog: likes, comments, follow a blog etc. This is what makes Truegit a platform and not just a tool. We want to make it Medium like publishing platform powered by Github.
Comment · 4 years ago
The biggest difference with the existing site generators and CMSs is that they are isolated deployments and each blog is completely independent. This makes it hard to gain audience. The goal of Truegit is to bring the social components: likes, comments, follow a blog etc. We want to make it Medium like publishing platform powered by Github. AFAIK, there's no platform that enables this.
Thanks for the Show HN tip!!
Comment · 4 years ago
Great question: I've commented on it here: https://graphql-eventbus.vercel.app/docs/principles/thinking...
See the "Specification for Event based communication" section.
"While cloudevents does have a promising specification, it does not provide any runtime guarantees. It's similar to OpenAPI: a specification that is hard to follow because nothing enforces runtime compliance with the specification. While this specification makes sense for public Event APIs, we believe that GraphQL Eventbus offers a lot more for building your enterprise event bus."
GraphQL eventbus does incorporate some best practices from cloudevents and event architecture in general: it creates an eventID and publish time for each event and propagates metadata like requestId.
Comment · 4 years ago
1. Not sure. I'm sure you can find something but not that I know of. Sounds like something that should exist.
2. I think of versioning as a two way process (at least for internal APIs): adding fields and removing fields. Removing fields could break your client but that's where the awesomeness of GraphQL shines. You know all the fields that are being consumed by your consumer so you can safely remove fields that are not being consumed. You can also mark fields as deprecated and this library logs a warning whenever a consumer is using that field. This property of explicitly asking for fields does not exist for protobuf so it's very difficult to remove fields.
More on this here: https://graphql-eventbus.vercel.app/docs/principles/thinking...
hope it makes sense!