Dev Docs

Dev Docs

  • Intro

›General

General

  • Getting Started
  • Guiding Principles
  • Case for Microservice
  • Case for DDD
  • Tech Stack

Frontend

  • React Basics
  • Styled Components
  • React Hooks

Backend

  • Getting Started with Serverless
  • Serverless and GraphQL
  • Making a Service

Case for Microservices

Lets imagine a startup at the beginning of their journey. There is a lot to do, and so often a few developers are hired and are given lots of freedom to build the businesses app.

Everyone does what they want

but if everyone does what they want, there is no garentee that any of it will work together, which results in bugs. Does not work together

To solve this problem, the company may choose a few people to come up with standards and best practices for the team. The one language, framework, database, libararies, and so on that everyone must use. Few people

This is great because now everything works! Everything works

But the team now has a bottleneck in problem solving. Even though there are 15 developers, the startup unintentionally created 3 problem solvers and 12 followers.These 12 are now only shadows of their formal selves. They cannot bring their whole selves to their job, they have to instead impliment someone elses ideas. What if someone has a good idea? What is the process for that good idea to now be implimented?

If it means that the 3 decision makers must first

  1. Become familiar with the problem this idea is solving,
  2. Decide if they agree
  3. Decide how this idea will be implimented in the companies best practices
  4. Decide if it worth the time for everyone else impliment this idea

Most of the time it will be determined that good ideas will cost too much, it takes too much effort to get everyone else on board and too much time to refactor everything to reflect this new idea.

The big problem with all of this, is that most of the time solutions are local, not global. But because we have 3 decision makers, every idea must be a global idea to solve a global problem.

So this is not a good scenario, but we still need stability. How can we have the stability of the blue scenario, and the creative freedom to solve problems of the red scenario. Microservices may be able to offer both.

Strict border If we use microservices, we can be strict with the border and liberal on what is inside. Stability is a border issue, or more accuratly an API issue. What language you use, database, libraries, frameworks, are no longer something you need to impose on the whole team for the sake of stability, it is now something that is determined on a per service basis, giving developers the ability to choose the best tools for the problem.

Strict border and unique microservices

So what does the border look like? Below is an example of the types of things you could be strict about. Strict border and unique microservices

← Guiding PrinciplesCase for DDD →
Dev Docs
Docs
Getting Started (or other categories)Guides (or other categories)API Reference (or other categories)
Community
User ShowcaseStack OverflowProject ChatTwitter
More
BlogGitHubStar
Facebook Open Source
Copyright © 2020 Your Name or Your Company Name