Micro vs Express (or Koa)

[deadcoder0904]

Googled a lot but didn't find anything useful
So maybe someone here can give any insight ??

[shime]

What are you looking for? Performance comparisons?

[deadcoder0904]

Anything & everything. Perfs come later but the main thing is how Micro differs from Express (or Koa). From googling, I got to know that Express comes with everything & Koa is minimal & u can use modules to add routing & stuff to Koa & Micro is same. So what's the difference between Micro & Koa bcz both are incremental ???

[deadcoder0904]

@shime Any insights ?

[rojerv]

+1, i'm interesting this too

[AndrewLosikhin]

Why did you forget about hapi js? I think we can also add that in the comparation list.
I also found API implementation based on micro
https://github.com/littleStudent/micro-authentication-starter/blob/master/index.js
Looks a bit complicated (overloaded).

[deadcoder0904]

@AndrewLosikhin I've seen Hapi & it makes a lot of others Happy 😂 but as a personal preference I'm used to Express & Koa is much smaller & simpler & is from the same people who built Express & Micro is much smaller so thought those 2 comparisons will help me choose one without much learning curve. As with Hapi, its awesome but personally I am not gonna use it yet. After all customers need something that just works, doesn't matter which language or framework is used for that.

[shime]

Seems like you figured out the difference between Express and Koa and you're now looking for
Koa vs. Micro comparison.

Differences:

• Middleware - The main difference. Koa relies heavily on the use of middleware, while Micro doesn't. You can find good explanation about that in Guillermo Rauch's comment here.
• Code base size - Micro is smaller with just ~260 SLOC, while Koa is ~570 SLOC.
• Request and response vs. context - Micro passes req and res around, while Koa uses ctx.
• Documentation - Micro lacks any official documentation, while Koa provides some on their official home page Micro's documentation is in the readme.

Those are the main differences I could think of. Perhaps someone more involved in either of those projects could chime in if you still have questions.

[sergiodxa]

@shime that's a good explanation of the difference. But what do you mean by Micro lacks any official documentation? The Micro docs is in the readme of this repository.

[shime]

@sergiodxa thanks, updated.

[deadcoder0904]

Seems like you figured out the difference between Express and Koa

That was never the problem. As while skimming through Koa docs & Quora I've seen people saying Koa is more like Express 5 but with Breaking Changes.

My main question is can Micro be used in a large scale application ?

[sergiodxa]

@deadcoder0904 we use Micro in a large scale microservice based application. The key is microservice, Micro is intended for that, while Express and other frameworks are intended to create a single HTTP server, you could you them for microservices but is not the original intentions of those frameworks.

[deadcoder0904]

Awesome thanks @sergiodxa
Keeping it open incase anyone wonders the same
Close it if you want

[styfle]

See #234 for disk space usage comparison.

TLDR; micro is now the smallest which is nice.

[timneutkens]

@deadcoder0904 maybe you could create a wiki article 👍

[deadcoder0904]

Don't think I need to, this issue explains everything 😃 & I guess Google will index it by now 😛

I just Googled Micro vs Koa & it shows it as the first link 😂

Problem solved 😄

[timneutkens]

Nice!

[corysimmons]

Unrelated to Koa vs Micro tbh, but @sergiodxa would you be kind enough to expand on this?

The key is microservice, Micro is intended for that, while Express and other frameworks are intended to create a single HTTP server, you could you them for microservices but is not the original intentions of those frameworks.

Where is the border between a microservice and an traditional API?

---

Update for posterity

Microservices are aptly named. Like... a server for auth... a server for managing S3 assets... a server for managing CRUD of product listings. The idea is to have a tiny service for every little thing (routes that are related like login and logout could/should belong to the same server).

These are more tolerant to someone (you?) screwing something up. If 1 server craps the bed, or gets DDoS'd, or you accidentally merge some bad code to production, then all your stuff doesn't die—just that one server.

Also, by doing this, you can scale certain services independently of each other, etc.

I think Sergio was insinuating Express doesn't do this as well because Express/Koa/etc. require middleware to do a lot of the standard stuff you'd do with an api framework. For instance, Express/Koa need some body parsing middleware, whereas this is bundled into core Micro (https://github.com/zeit/micro#body-parsing) and is opt-in (e.g. const { json } = require('micro')) whereas body-parsing in other frameworks might be a catch-all (e.g. .use(myRoutes).use(bodyParser).listen(...).

On top of all that, Micro and its deps are significantly smaller/better-performing than other frameworks, which is important when you consider your API might be slammed by millions of requests. Those 10ms differences add up quick.

The microservice approach has a lot of big and little benefits, but you end up writing a lot of the same boilerplate over and over for each of these repos, so a significantly smaller codebase + opt-in API saves a lot of disk space, and time in development as well.

A personal note about middleware: people bloat ecosystems with it and then don't maintain their middleware. You really only need body-parsing (bundled in Micro) and routing (microrouter's approach is pretty elegant) to do pretty much anything well.

I might be wrong about parts, or all, of this. Someone correct me if so.

[ithinco]

@sergiodxa Hey, so do you have any recommendation of service discovery and api gateway solution for micro? THX

[Telokis]

@sergiodxa I'm very interested in the question @ithinco asked!
I'm trying to wrap my head around microservices and the routing part is what seems the strangest to me.
I have all those single-purpose servers but how do I make my client know which one it should talk to depending on what it wants?
And, moreover, if I have overlapping data, should I have one giant database which is accessed by all microservices at once?

[styfle]

I have all those single-purpose servers but how do I make my client know which one it should talk to depending on what it wants?

@Telokis I believe Now v2 attempts to solve this problem by deploying a monorepo with many services.

See the blog post (specifically the section about the monorepo) here: https://zeit.co/blog/now-2#the-majestic-monorepo

[sergiodxa]

@ithinco @Telokis I don't have any specific recommendation for Micro, any Service Discovery and API Gateway should work fine with Micro, is just a normal HTTP server at the end of the day, nothing special.

Now v2 has definitely interesting things for that like being able to define routes when deploying to match your microservices entry point, but so far is missing a Micro builder for Now.

@corysimmons what you said here

On top of all that, Micro and its deps are significantly smaller/better-performing than other frameworks, which is important when you consider your API might be slammed by millions of requests. Those 10ms differences add up quick.

Was what I meant, Micro is far smaller than other alternatives, is like building a microservice with Rails/Django/Laravel, you can but do you need a whole framework for a simple service? Nope, instead you can just code it yourself using the native HTTP module or in this case a tiny abstraction to simplify it a lot.