In my experience so far when making some kind of full stack web application I run into problems with the programing becoming to complex. Often is the case so far that I end up doing everything in a single application. That is rendering and delivering the client system, authentication, database management, and so forth all within a single package. When it comes to simple hobby apps that are not that complex, and may never have more than 50 visitors at any given moment, maybe this is not such a bad thing. However as a project grows in both complexity, and or popularity there is a threshold where it becomes desirable or necessary to break things down more.
One way to do this is to start to get into micro services using node.js, and the popular express.js framework. In this post I will be writing about a simple example that will be just that.
There might be a lot that comes to mind when aiming to not just make a micro service, but a production code worthy micro service. When this is the case a great deal of things might come to mind like scaling to meet demand for the service that is being provided, and how to go about sharing information between services. However as I understand it a micro serive just needs to meet two simple criteria.
- It provides one or more services of some kind.
- It is deployed to the web, and can be used by way of an http request.
In other words if you take a complex full stack web application, and break it down into smaller pieces, and have each pieces deployed separately. I would say that one of the pieces fits a loose definition of a micro service. There is a great deal more to it than that of course, but at the core of it that is the idea.
I have been toying with the idea of making a game about bogging. The idea is that people sign up to start an account, and then write short simple blog posts to make in game currency. The amount of currency made depends on how well the posts rank, and how many other people visit them. This might just be yet another one of my unfinished prototypes, but at the very least I should end up making at least one simple micro service example in the process.
I am sure that I will want to keep track of the volume of certain keywords to be used as a way to determine keyword value. So for a simple example of a micro service how about something that just keeps track of a simple count of keywords.
For this demo I will want to make a keyword service that just keeps a simple count for each given keyword. It will have to except post requests for a keyword, and create a database record, or update an existing one. In addition it will have to respond with a count for the given keyword as well.
Also I will need another separate project that will make use of this service.
So for this demo I will actually be making two projects, one will be my micro service, and the other will be an app that makes use of this service. For the keyword service I will want to use express.js, and some kind of database solution. For a simple hobby project like this lowdb will work just fine for now. The other app will be something that just provides a client system, and back end that makes use of this service. This app will not be the highlight of this post, so I can just quickly throw something together involving something like express, and jQuery maybe.
So the micro_keywords_main demo will just serve up some static assets, and make post requests either directly to the service from the client, or indirectly via it’s back end by making the request with the node.js http module for example. The other project micro_keywords_logger will be the actual micro service demo for this post.
This project just needs to have a single app.js file at the root that will make a database for the keywords if it is not there. It will accept incoming post requests, creating a new database record, or updating one that may all ready exist, responding with the current count for that keyword. For the purpose of this post this is all that it will do for now, however going by the definition I have given it meets the basic idea.
So at the root of the service I have an app.js file like this:
I am using mkdirp to make sure a folder exists before creating a file there. If interested I have posts on both mkdirp, and lowdb if interested.
So this is a quick project that I threw together to make use of my micro service. This is not the highlight of this post. The idea here is that a micro service should be kind of independent from the rest of the project. It is okay if that is not the case, when getting into some things that are really involved it might be unavoidable. However I would say that a well designed micro service is something that can at least potential be used from a back end, or front end system, from the same domain or even maybe a different one.
So for this demo though I just put together a simple back end that will not start if the micro service is not running before hand, and will make the call from a node.js environment rather than the browser.
There is a whole lot more on micro services to write about, however this is just a getting stared post in which I am just covering a very lose definition of what a micro service is. If you are aiming to make a complex full stack application it is important to avoid the tenancy to do everything in a single app that will be placed in a single deployment.