How to use micro with two routes?

[rafaeljesus]

How would I design a service with more then one route?

For example I have a event-trace-api service where I trace all transactions in my app and expose a api where I can search for these events,

So basically I have 2 routes:
POST /v1/events
GET /v1/events/search

Following micro design I would have 2 separate servers, one for create and other for search, that looks too much for me,

Thanks

[sergiodxa]

I think you should use search as a query param instead of part of the url, then you can just check request.query.search and if it's undefined return the full list.

If you want to use search as part of the url then I'm sure you should to use 2 separate servers, one for the complete list and other one for the searched list.

[rafaeljesus]

Hi @sergiodxa thx for your reply,

That's not very intuitive to have one route to deal with POST and GET

Looks like micro is a nano-service lib and that's totally fine I think

[sergiodxa]

Micro is just to create HTTP services using async/await and thinking in microservices, it's a wrapper for the http Node.js native module. But it not give you a router handler, you can use other router handlers which can receive the request object.

Thinking in how made that what about something like this?

import micro, {
  json,
  send,
  sendError,
} from 'micro';

/**
 * handle POST requests
 */
async function postHandler(request) { /* ... */ }
/**
 * handle GET requests
 */
async function getHandler(request) { /* ... */ }

/**
 * Check the request method and use postHandler or getHandler (or other method handlers)
 */
async function methodHandler(request, response) {
  try {
    switch (request.method) {
    case 'POST':
      return await postHandler(request);
    case 'GET':
      return await getHandler(request);
    default:
      send(response, 405, 'Invalid method');
      break;
    }
  } catch (error) {
    throw error;
  }
}

/**
 * our micro service, run methodHandler and send result as a response (or an error)
 */
const server = micro(async (request, response) => {
  try {
    send(response, 200, await methodHandler(request));
  } catch (error) {
    sendError(request, response, error);
  }
});

server.listen(process.env.PORT);

This way you have a function for each valid method.

[rafaeljesus]

@sergiodxa thank you very much for your explanation,

I thought doing this would go against micro principals design,

And this design totally fit into my trace-events-api service that I have running in production now,

Cheers

[rauchg]

@sergiodxa that's a beautiful example. Thank you for contributing it.

If you want routes, you can write another micro service that maps routes to backends, or use something like Nginx. You would host each of your services under a subdomain or port independently.

We're running 20+ microservices already in production. We had to use routing once, and we simply looked at req.url and performed a simple string comparison.

If you need a sophisticated routing mechanism, you're probably doing too much in one Node process. You'll pay in the form of more complicated debugging, conflated logging and lack of error isolation.

[rauchg]

Based on your example, in fact, I see that you want to do versioning. Not having routing built in is great for this.

Let's say /v2/events/search is the same, but /v2/events POST changed. You basically can bump versions by simply forwarding all v2 traffic to the existing v1 backends, and only add one exception, for /v2/events to go to add-event-2.0.0.yourhost.com. URLs are just labels!

[rafaeljesus]

Great explanation @rauchg

I'll think on how to design this on Heroku, I don't have nginx right there,

So basically, are you doing in your production servers "one server for one route"?

Cheers

[rauchg]

Indeed. I have no experience with Heroku.

[rafaeljesus]

But hey I'm going to remove koajs form some microservices in production and use micro right now \o

[diorahman]

@sergiodxa I'm not sure we have request.query in micro's request object. Or I'm wrong?

[sergiodxa]

@diorahman yes, I just tried it and in the request object we don't have request.query, but it's possible to use url and querystring to get it in one line.

import qs from 'querystring';
import url from 'url';

async function requestHandler(request, response) {
  const query = qs.parse(url.parse(request.url).query);
  // do something
}

[onbjerg]

What about resources? E.g. the user with ID 1 would usually be /users/1. What would this look like in micro?

[sergiodxa]

I think you should do that yourself (I suppose with a RegEx), but I will quote @rauchg here:

If you need a sophisticated routing mechanism, you're probably doing too much in one Node process. You'll pay in the form of more complicated debugging, conflated logging and lack of error isolation.

[rauchg]

A simple match utility would be nice for that. Not sure if it exists but:

const { id } = match('/users/:id', url);

would return {} for no match (eg: '/user'), { id: 1 } for /users/1 etc. Kind of saves you the trouble of checking that the regexp returns null, looking for the index of the capture group, etc.