Critique my approach to building a blogging engine

Chat / Discussions
,
1

Hey all,

So I’ve decided to build a little blogging platform to integrate into an existing Phoenix application that I’ve built. For now the Phoenix app is just a little web server serving a single page app with react and a postgres database on the backend to collect some contact information from users. Not much to it.

To drive traffic to the site I want to add some blog functionality at the foobar.com/blog endpoint. Originally I was going to use something like Ghost to save time, but decided to get more hands on. Of the existing Elixir blogging solutions my favorite is Nabo, but after digging through the source code I’ve decided to roll my own and open source the solution.

Ultimately my goal is to be able to iterate this code over several sites that I’m building, all of which will have some kind of content/blogging component. Some of these might be entirely focused on serving written content. These will likely all be Elixir apps that depend on Phoenix for web service in some way.

My options as I see them are:

  • Write a non-OTP blogging kernel library that has modules for fundamental interactions for Article, Category, Tag, Comment, etc, and all the good stuff that could then be included/imported/used inside of any elixir/Phoenix platform. I guess it would have to make some presumptions about what the corresponding repository tables would look like, probably including some generators or something of the like. However the goal would be to abstract all of the common business logic surrounding writing blogs that’s a pain in the ass to write over and over again.

  • Write a library as an OTP application that does fundamentally the same thing, but that is intended from the outset to be an OTP application could then just be hooked into any existing Elixir/OTP application. I guess this would behave more as a standalone solution, and could probably just even be dependent on Phoenix. It seems like this would probably be less flexible than writing a set of tools that are fundamentally independent of how/where they’re being implemented, but would probably be easier than integrating them into an independent Phoenix app every time I want to deploy a new blog, which is probably what I’d end up doing.

This may all be a bit fuzzy as I’m presenting it from 10,000 ft, and I understand a lot of this is a matter of taste, but I thought it might be useful to solicit some opinions here before I commit to one approach or another. Hopefully this is something that will become useful to the community at large, so it seemed to make sense to open this question up to the community from the outset.

Do either of these seem more useful/accessible to you? Is there anything in particular you’d like to see come out of the Elixir community in terms of libraries to support publishing content?

Thanks in advance for any feedback.

~ Mike Zazaian

2

I’d for for it being an OTP library rather than an OTP application, this way someone could potentially even spool up multiple ones with different settings if they so wish. :slight_smile:

Plus integrating it in someone’s existing setup would just be a single-liner in their parent supervisor anyway. ^.^

2 Likes
3

@OvermindDL1 as always you are a force to be reckoned with. When you say OTP library, do you just mean a library leaning on Genserver to manage state internally, and providing its own parent supervisor for spooling up? Is the distinction here that the application wouldn’t have to be started by the OTP application controller, but could just be integrated into any supervisor tree?

Thanks a ton for your feedback here. As always it’s highly valued.

2 Likes
4

Correct.

When something is configurable like that with potential to be used multiple times, it’s always best to make it an OTP library that can be integrated into another OTP Application. You can of course have it have an OTP Application as well that is default enabled/disabled too if you want, but configurability is important. :slight_smile:

As an example, my TaskAfter library does this, you can see the docs how you can set it up for a global or local installation (or both) just by defining a config entry or not. If global then it has it’s own application that starts everything up, if global is disabled then it just doesn’t start anything. It’s pretty simple code if you want to look at it. :slight_smile:

4 Likes
5

Got it. That definitely clarifies your point here. Sounds like this might be what I was digging for. I’m in Germany ATM so it’s late o’clock here but I’ll check out your TaskAfter code and get back to you about this. Either way this sounds like a really common sense approach to an OTP library

1 Like