Hacker News new | past | comments | ask | show | jobs | submit login

I am still trying to wrap my head around microservers and maybe someone can help me. Say we are building a blog platform.

1. Would it be separated into the following services: user, post, and comments?

2. If I was designing this in flask or django, would each service be running on localhost with different ports, e.g. user is localhost:8080, post is localhost:8081, etc?

For my personal flask project, I am currently following this style http://mattupstate.com/python/2013/06/26/how-i-structure-my-... with service layers.




The point of a microservice based architecture is to allow a large team (15+ people) to work together without stepping on each others toes. The idea is you break the application into smaller services, and each service can be iterated on and deployed by a small group of 1 to 4 people. I cannot see any reason why it would be a good idea to adopt a microservice architecture for personal projects or for a startup with less than 10 people.

I did work on an application suite that included a blogging platform, that aimed for a service based architecture. We had services for: * taking screenshots of the rendered blog post, for use in preview thumbnails * user identity and settings (shared service for the entire suite) * asynchronous task handling * sending emails * adding blog post analytics to the dashboard * all things commenting (including a javascript embed code) * the main application for editing and rendering the blog content * customizing blocks of content based on visitor identity


> 1. Would it be separated into the following services: user, post, and comments?

No; posts and comments would likely be provided by the same service. Users, on the other hand, are likely an abstract idea implemented across several services (an authentication service, a profile service, etc.)

An easy way to think about it: if your business logic needs to do the equivalent of an SQL JOIN on data from both A and B to compute some common query (e.g. displaying a page with a post and comments on it), then A and B likely belong to the same service.

If, on the other hand, you have data/state that can be encapsulated into its own black box that none of the rest of the code needs to know the internal structure of (e.g. user authentication information: password hashes, 2FA token seeds, session IDs, etc.) then that data/state can be isolated to its own service.


Using separate services for posts and comments is incredibly common, though, considering how many sites use a third-party service like Disqus or Facebook to provide comments. If you're expecting to load comments in JavaScript (which is really common these days to reduce load time and the impact of link spamming), implementing comments as a separate service where groups of comments are keyed by origin URL or article ID is a no-brainer.


True. I was more imagining discussion sites like this one, where a post is basically just a special parentless comment that's rendered differently, and all normalized tables that connect to one also connect to the other (e.g. both posts and comments are associated with a user profile, both posts and comments have a point score, etc.).

On a plain blog, where "people who post" and "people who comment" are basically disjoint sets, comments can indeed be separated out into their own service, which may indeed be a gateway implemented by a third-party RPC consumer object.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: