-1

so I'm working on a website project with the goal of writing my own blog posts with markdown syntax. I made some thoughts regarding the handling of the markdown and the conversion to HTML, storage solutions, performance and flexibility. I'd like to get your thoughts and experiences regarding this, trying to find the optimal way to tackle this problem.

I'm working with ASP.NET Core and C#, Razor pages, MSSQL and obviously things like HTML, CSS and JavaScript.

When you write a post in markdown, you have to store this markdown somewhere. I plan on storing this in my MSSQL database. (related question) Do you agree that this is the best way of handling it?

I'd like to download images references in the markdown onto my server to guarantee the availability once used in a post. I plan on storing these on the servers filesystem with an updated reference in the markdown (related question). This requires me to parse/extract the markdown to find the relevant usages, how would you do this? Would you even bother to do this? A potential benefit I see with this is the ability to log/track the access of those images through an API or similar and also localize the URL used for the images.

When a user wants to read a post he of course doesn't want to read markdown, but a rendered version of it in HTML. Would you process/convert the markdown every time a user opens the page (potentially even clientside) or would you pre-process (e.g. with Markdig) it and store the raw HTML besides the markdown in the database aswell? I'm concerned about performance issues and SEO problems. I thought about writing my own markdown processor to get more flexibility, I'm not sure how smart this is. I'm less concerned about security (I'm probably going to be the only one using this software) and potential exploits than the reliability of it. Also, how would one apply custom styling to it (e.g. for code snippets?) and so forth.

Also, I'd like to implement a WYSIWYG editor into my frontend, similar to how StackExchange and others use it (e.g. StackEdit). Are there any potential downsides to having an editor like that?

Thanks for you inputs, appreciate it.

  • 1
    Two comments I’d make here. Firstly, unfortunately this question is off-topic here as it’s way too broad. We do not provide assistance in designing a complete solutions. Secondly, why reinvent the wheel like this? Solutions like Github pages already exist and do exactly what you are after, so creating your own solution seems like a massive waste of time to me. – David Arno Oct 13 '18 at 9:03
  • @DavidArno I see, I wasn't sure where/how I should post these questions. I've spent a few hours searching for already existing solutions but all of them were either based on a technology I didn't want to use (e.g. PHP), were a massive overkill for my purpose or didn't provide the flexibility I desire. .. I figured since I'm a software engineer I might aswell build it myself. – Tobias Würth Oct 13 '18 at 9:18
3

so I'm working on a website project with the goal of writing my own blog posts with markdown syntax.

Why? What's wrong with the existent solutions?

I plan on storing this in my MSSQL database. (related question) Do you agree that this is the best way of handling it?

I wouldn't agree that this is the best way. It is one of the ways to do it. For my blog, I used MongoDB. It is neither a better, nor a worse choice.

I'd like to download images references in the markdown onto my server to guarantee the availability once used in a post. I plan on storing these on the servers filesystem with an updated reference in the markdown (related question). This requires me to parse/extract the markdown to find the relevant usages, how would you do this? Would you even bother to do this?

There are a lot of issues with that:

  • You shouldn't be covertly modifying the original post. You can use the technique used at Stack Exchange where the user can upload images, but modifying the original Markdown without the consent of the user is both risky (you can unintentionally screw up with the post) and misleading (as a user, I would be highly surprised to see all my links replaced by something else under the hood).

  • You open your site to potential attacks (if you are not the only one who can post articles). What if the image is not an image, but a malicious script that you'll save to your server? Or what if the image is 5 GB large, making a DOS attack extremely simple to perform?

  • You make it possible to use your site to attack other sites (if you are not the only one who can post articles). Imagine a script posting, again and again, a message containing a few thousand links to images from a given server. You will be now the one performing a DOS attack on the server hosting the images.

  • There may be legal issues as well. If an image is copyrighted and you clone it to your server, you may be in a big trouble.

  • Images are the thing which makes a heavy use of the bandwidth. Why would you pay extra bandwidth for that, instead of letting other servers do it?

A potential benefit I see with this is the ability to log/track the access of those images

Why would you care about that? You already have the statistics for a given article. Google Analytics will give you even more information about the users.

Would you process/convert the markdown every time a user opens the page?

The same Markdown always produces the same HTML. Therefore, there is no need to generate it again and again every time someone visits the page.

Store HTML side by side. Update it when Markdown is modified.

If, for some reason, it's easier to generate HTML when a page is shown, then at least make sure you rely on aggressive caching.

By the way, if you are not the only one who can post articles, letting the generation of HTML happen during the page load makes it easy to perform a DOS attack. A malicious Markdown (i.e. specifically crafted so that the conversion to HTML would take a long time) could be injected, and then, the attacker would simply call in a loop the page showing the article.

I thought about writing my own markdown processor to get more flexibility, I'm not sure how smart this is.

Not smart. Markdown is relatively complex to parse, and you will introduce bugs. Those bugs could then be exploited to hack your server.

The existent implementations of Markdown to HTML conversions are relatively stable and many of them were reviewed by a lot of persons. Unless your project is specifically to create a competing converter, just use the existent ones.

Also, how would one apply custom styling to it (e.g. for code snippets?) and so forth.

Some Markdown to HTML converters can be customized to enable the use of custom tags.

Also, don't forget that HTML elements can be put within Markdown.

Are there any potential downsides to having an editor like that?

One of the issues is that you'll have two Markdown to HTML converters: a server-side one used to generate the HTML which will be displayed later to the readers, and a client-side one which will show contents to the writer of a blog post. Maintaining both is not particularly difficult, but it still requires additional work. Some features which are available in one may not be available in the other.

You can of course use only one converter by making AJAX requests to the server every time the article is modified. However, this you need to be careful to avoid doing a request at every character typed: for long or slightly esoteric articles, it will use a lot of resources and bandwidth.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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