8 pages about "Ideas / RFC"
A website / an app that suggest you a random book.
Get referral fees.
Get interesting results: various, but with a minimal quality level.
There are two main ways of using GraphQL:
- as the core method of defining & accessing APIs
- as an alternative way of accessing existing APIs (a proxy)
The original idea here is not about the technical way of doing it as it is pretty standard.
I focus on a specific context where this idea may become very interesting:
- An heterogenous system,
- made of mixed protocols (Rest, gRPC, GraphQL, …),
- multiple languages,
- standalone/autonomous teams (not working in the same office),
- legacy code,
- third-party services,
- mix of big monoliths and small micro-services,
A Central GraphQL for Big Organizations is a tool that allows to aggregate everyone on a common format while preserving the diversity of the ecosystem, with a very limited risk, and with “free documentation” as a bonus.
It may also be a solution for smaller organizations as the secret is to only involve a small team or even one person to bootstrap the project.
- choose a way of defining contracts
- You can choose to write in the GraphQL definition format directly, in protobuf and then generate the GraphQL code, probably even in swagger, etc
- implement (at least) two different services using this format
- bootstrap a PoC implementing the two services, you may have to develop some “drivers” for common feature: authentication, retry policy etc
- show your PoC to some other key people (architects, team leaders, etc.)
- motivate people to help you write missing API specifications and “drivers”
- you now have three options:
- to try to make everyone fit in the same API formats and everything (your initial plan?) 😉
- or ask them to maintain a specification file for their existing APIs
- you can now use advanced features of GraphQL: cross-services unions, streams, validation, type safety, client code generation, etc…
- it can be tested without risk, if this project fails, you only involed a small team, not the whole organization
Create a tool that allows to colleboratively define, visualize (with graphs) and query dependencies.
a.k.a. “The perfect mix between Neo4J, Wikipedia/Wikidata, and LucidChart“
- can be done manually
- can be done using scripts/APIs to aggregate external sources
- should be typed yet flexible
- Wikibase, the engine behind https://wikidata.org, to store and manually manage the dependencies
- An existing or a custom solution to import/synchronize existing data
- Well-defined base entities to ensure a good overall quality
- A custom frontend to provide useful visualizations
- Some process/guidance to have collaboration
Remake of Little Alchemy with collaborativity in mind.
Two collaborative modes:
- Administrative collaboration: people can easily propose new alchemies to the community.
- It can easily be done thanks to open-source, basically, only a README file or a CONTRIBUTING file in an open GitHub project, and voila.
- Playing collaboration: being able to play in teams to share the fun.
not so much, just taking the time to setup the engine and have a decent UI.
A blockchain that works over Git.
Git already supports:
- cryptography signatures (
git commit -S)
- multi approver signatures (
git commit --signoff)
It’s technically possible to port the consensus workflow using basic git commands.
By adding a CI/CD bot/script, it becomes possible to have an equivalent of smart-contracts that only allows people to open pull-requests while having a robot to make the merges.
Finally, we can find about having a proof-of-stakes approach based on git contributions or something more centralized as a
.forgers.txt file that defines allowed forgers.
Find other parts of what makes a blockchain:
- how-to define/allow/deny a node to be a forger in a distributed way
- create a small utility that makes the git commands automatically
- automatically generates with the CI/CD a static blockchain explorer
No idea yet.
It can be used as a pedagogical support to learn how the blockchain works.