I am building a personal blog system. The system is more like a platform, means that not only the admin, but all registered users can post their blogs.

We've decided that using markdown as the blog's written language, thus we provides a markdown editor in the front end, and the editor will update in real time when the user do some writing. So in the client side, we must provide the ability to render the markdown.

Since it's a blog system, SEO is something that we must considered, i know that Google can run some Javascript code when do their spider job. However, some other search engines that i have to work with don't have such ability. So total client-side rendering strategy(for the blogs pages, which might be identified as /blogs/:some-id) cannot be performed.

As i mentioned before, the front end have markdown render ability(code). We don't want to repeat it in the back end(or else, we might need to maintain two different markdown render configuration and do some brittle job to guarantee that the server side's render have the same output as the client side editor).

So we turn our eyes to prerender and SSR.

With SSR, the point is, for some reasons, we construct our back end server by Java. So it means that we might need to add a new middle JS(node or...) layer between the front end and the back end to do the render job. In this way, how to separate the duty between the middle layer and the back end layer, like intercepting all the request in the middle layer, the middle layer handle the /blogs/:some-id rendering request, and forward all other request to the back end server?

With prerender, for example, we might want to route all /blogs/:some-id to prerendered pages. There are also some problems. First, the blog page is not only consisted with static content, but also some dynamic content like other users comment. Second, to handle the modification of the blog, we might need to add a hook in the back end. Each time the blog's content updated(add/remove/modified), we need to recompile some pages, that seems a little bit weird to me(but i cannot tell why), and need the prerender components have the ability of incremental compile the static container.

Or some other architecture might be the better choice?

1 Answer 1


Server-side rendering is definitely a good choice.

For one of the projects where I was involved SSR was not an option because our SPA framework didn't support it. So we came with a solution which is by no means a design guideline to you but instead is an interesting option you might want to consider.

Our project was hidden by a reverse proxy (Nginx). So we've detected whether the request comes from a crawler. In such way we've evaluated a dynamic content via puppeteer and served it to the crawler. Otherwise, we've served an original version of the site to the client.

  • Thanks for your reply. How to separate the duties between the render JS layer and the Java back end? For example, the JS layer handle all the render request and forward other request to Java back end? Oct 23, 2019 at 13:13
  • That is a valid tactic. Anyways all your business logic should be represented on java backend. Oct 23, 2019 at 13:42
  • What about the prerender solution? Any pros and cons? Oct 23, 2019 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.