Implementing a Microservices Architecture on my ‘Bookmarks’ Application

For the last few weeks, I’ve been developing a bookmarking and link shortening application. (Click here to view the latest commit as of the time of this writing)

I’d built out most of the backend logic, but ran into an issue with the frontend. As I started introducing frontend tools, frameworks, and libraries, my application started to feel like it was becoming hard to maintain.

I also realized that if a developer wanted to implement my code in their own application, it would be very difficult. They’d have to remove all of my frontend code to replace with their own.

Almost like divine intervention, I started hearing a lot about microservices. I didn’t fully understand what it meant, but from what I did know, it seemed like it may help with my issue.

So I did a bit of research and rethinking of my application.

Here is what I found.

My Intro To Microservices

The first time I had a solid understanding of the concept of microservices was when I read Netflix’s blog post discussing how a new form of DDoS would target its microservices architecture. I saw how Netflix’s applications were really made up of a number of tiers of services all handling different aspects of the application. This helped me conceptualize the microservices architecture.

When I did more research into the microservices architecture, I discovered that it basically is about splitting an application into separate services. Each service acts as its own application in a way. They each can have their own environment, including hardware, software, and database. And usually they communicate over a network (most likely via HTTP).

The upside to a microservices architecture is that it makes everything more maintainable and scalable. Because of the modular nature, each service can be easily rebuilt or replaced with another service. It just needs to follow the protocols set up for each service to communicate. Abstraction at its best!

You can learn more about the specifics of microservices here.

Refactoring the Bookmarks Application

Analyzing my bookmarks application, I see how I can split it into 2 different services.

The first is the bookmarks API. I can build a REST API that controls the creation and lookup of bookmarks. A user can send requests to create a new bookmark, look up the URL of an existing bookmark, and view all bookmarks they’ve created.

The second service would be the web application. It would be user facing and handle the UI as well as user authentication (maybe in the future I’ll split this up too).

The nice thing is that any developer could take my bookmarks API code and easily make their own bookmarking service from it. I also have the possibility of creating different applications which utilize my bookmarking service. Or I can open my deployed bookmarking service to anyone who wants to use it to build their own applications.

Final Thoughts

I have a few things I still need to figure out:

  • Architecture of the bookmarks API
  • How to authenticate users of my API
  • Connecting the web application with the API

I plan on writing a few followup posts as I complete each task.

If you have any suggestions on ways I can improve what I’m doing, please let me know.

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s