The Micro development roadmap, team and contribution guide.
Micro is the simplest way to build microservices. Our goal is to continue on this mission in an open and collaborative way, both as a team and community. Up until now most of our ideas and development have revolved around discussions in Slack.
This useful for realtime collaboration so we can move quickly but often means not everyone gets to contribute or we don't have a history for others to go back and look at to understand how we got to where we are.
This repo serves as an open forum for long term design ideas, collaboration and ultimately the roadmap for Micro.
- collaboration - the tools we use or will use for collaboration
- content - types of content we need e.g examples, posts, tutorials
- design - where the design docs live
- hiring - the interview process for hiring
- onboarding - onboarding guide for new developers
- productivity - how to split work and time to be productive
- roadmap - where the full roadmap lives
- issues - where we track work
- pull requests - where we start new docs
- team - a checklist of resources to provide access to for new team members
- glossary - a glossary of terms and explanation of brand, company, project, product
This is a high level overview. See the detailed roadmap.
- consolidate all libraries into go-micro
- gRPC API for the micro proxy
- quic as a default transport
- nats as a default broker
- gRPC integration and interop
- embedded nats as the default broker
- go, java, typescript, ruby, python client libraries
- standalone micro server
- better documentation and end to end tutorials
- simpler kubernetes integration by default
- pluggable wrappers for go-micro itself
- more flexible options dynamically defined as flags and env vars
- improved micro api configuration
- graphql handler for api
- define the mucp protocol
- reusable foundation services
- define the mu definition
Micro is the simplest way to build microservices. We have a developer first focus. Our goal is to make developers incredibly productive, to remove friction from their workflow and abstract away the complexities of distributed systems and cloud-native technology.
Our approach to this is very clear. Any new project or any change that we make must come from a developer's perspective.
Here's how we approach taking on new problems.
- Engage the community about the problem and how we need to solve it.
- Discussions lead to clarity in thinking
- We can work through ideas before actually spending significant time writing code
- We can understand if we're even solving a problem
- Define the overall scope of the project and name it.
- e.g Auth, Config, Debug. This is the domain boundary
- Go Micro deals with inter-service communication
- Go Config deals with dynamic configuration
- Micro API is an API gateway for HTTP requests
- Start with a Go library/package, this is always our starting point, we want to solve for the developer in Go first.
- Define separate packages for sub-scopes of the domain
- Start with the high level interface that will be used. Implement it and make it pluggable
- Ship quickly and iterate, test the ideas with the community.
- Go Micro was being used 2 weeks after the first line of code was written. It was called something else back then.
- Encapsulate as a command/service in the Micro toolkit so that it solves the problem across all languages
- Go Micro is at the core of all the toolkit components for discovery and inter-service communication
- go-micro/api is the basis for the Micro api
- go-micro/config will be turned into a dynamic config server with a gRPC or HTTP api
- Everything that we do focuses on simplifying the experience for the developer
- Provide a zero dependency default experience while being pluggable
- Abstract away cloud-native and distributed systems. Operations is a separate concern
- Build on our own foundations rather than those of others.
- CNCF projects are complex, fast moving, breaking and we have no control over their long term goals
- We want to own the foundations so we can build on them and focus on making developers productive
- Where other tools solve complex problems we offload with plugins or abstract them away
- Open an Issue to start a discussion with the community
- Open a Pull Request to add a design doc where you've already got strong ideas
- Help shape the roadmap for Micro and be a part of the microservice movement
- Take any real time conversations to the #development channel on Slack
The coding style guide is fairly straightforward.
- KISS: - Don't use complex algorithms where a for-loop would do. Just keep it simple. We'll fix perf later.
- Brevity: - Don't use long variable names where a comment would suffice. Do the minimal work.
- Consistency: - See the surrounding packages, variables and types as a guide for how you write code.
When you are contributing whether it be bugs or features you are the owner of that through to completion.
The workflow is as follows:
- Discuss: Talk about the the bug or feature in #development with others first
- Document: Create an issue and todo note to track starting and progressing the task
- Deliver: Create a PR for your bug of feature and engage at least 2 other team members to review
- Validate: You should be testing throughout but once delivered its your responsibility to validate full functionality