Cochonours

Cochonours

I wasn’t meaning to add hooks every where so the code becomes a nightmare to understand, but indeed taking advantage of pipelines. One still needs to define where the plugins can inject their functions (in the pipeline, before rendering, after rendering, …), I don’t see a way around that, and every new hook like this makes the whole more difficult to understand when a bug appears.

I’m with you on this. It’s a trade-off but making them orthogonal would prevent a lot of headaches and nasty bugs. There is always be someone who wants to alter the functionality of another plugin in a way that wasn’t designed, but you could scratch that.

One DB per plugin is just the easiest/quickest way to make it work while ensuring total isolation and programming ease, but any other ways like you described would be acceptable. Your app will have to handle all that new user in DB + setup all rights + creating the table and vice versa when the user pauses or uninstalls the plugin. My idea is only to be able to ensure that plugins cannot alter in any way data that do not belong to them, and let the plugin writers in charge of their own little migrations orthogonally. Non technical users shouldn’t have to care about the how.

I’m used to this kind of thing and it’s not so bad, but indeed as other said it seems to be easy to just keep it all in elixir. Keep in mind that allowing several languages with a (strict) API allows people from various backgrounds to write or import plugins, which could be a plus. It’s also a minus as the bar of entry will be lower, so…

0
Post #11
Cochonours

Cochonours

We are talking about a few DBs, at most a few tens of DBs (which would already be a lot of plugins installed), so keeping those connections open is peanuts. It’s better performance wise to have one table per plugin and let the plugins use joins to other tables from the app DB, but in that case it’s quite a lot more complicated to handle data access and security. If you don’t allow joins and let the plugins only use their own table the performance cannot be better than one DB per plugin (as in this case each plugin can use the type of DB that is the best for the job).

Is that really a plugin system anymore? The app devs have to carry the burden ad vitam, and the probability of spaghetti code becomes much higher, making it impossible to remove/extract a plugin a few years down the line.

0
Post #12
adrianrl

adrianrl

I don’t know if I understand what you’re trying to say, but querying another database implies joins too, you may want some kind of relationship between the plugin and the app.

Why not? It just works and it’s more straightforward to implement. The problem here is recompiling the whole application in real-time for every installed or upgraded plugin, think about a new installation where you may install a bunch of plugins to check if they are useful for your project, not only plugins but also themes, I think it’s not worth it. What would happen if an installed plugin tries to call obsolete APIs or isn’t working correctly? Big disaster here.

Why spaghetti? Think about this structure:

CMS_web/
  plugins/
    plugin_news/
    plugin_seo/
    plugin_stripe/

And then:

defmodule CMSWeb.Plugins.PluginNews do
  # ...
end

As you can see each plugin lives in their own module, so this kind of organization should be enough to avoid repetition. I worked on a custom CMS system for two years or so in PHP, and we never consider that we had spaghetti code, even using OOP that sometimes is totally a mess of abstractions.

1
Post #13
dimitarvp

dimitarvp

Now that LiveView exists and will be improved even further in the near future, I believe the time is right for a Phoenix-based forum software.

It will be no small task however and realistically I don’t think anyone will tackle it without several years of guaranteed salary.

1
Post #14
runexec

runexec OP

Hm… Milestone bounty?

0
Post #15
peerreynders

peerreynders

Wouldn’t that just be retreading ground covered by incumbent solutions already? Seems the current opportunities for innovation are on the client side (web), e.g.:

  • Store recent, bookmarked topics and posts for offline viewing
  • Queue posts in offline mode for later dispatch when connectivity is available.
  • Updating of offline topics with background-fetch
  • etc.

Of course that is going to require a server side API that can support that style of distribution.

1
Post #16
l00ker

l00ker

In my opinion it has more to do with shared hosting. PHP (and MySQL) have been included with just about every shared hosting plan on the planet and is IMHO the main reason behind the popularity of PHP in general. I used PHP (and still need to) for years to that very reason. It isn’t until you actually need a long running process that you move on to greener pastures, like Python, node.js, and (now for me) Elixir.

There is a project that was started a while back but it hasn’t been updated in a good while: Contento

4
Post #17
dimitarvp

dimitarvp

Technically yes, in practice no. Older versions of PHP – those still dominating usage on I’d bet most hosting services on the planet – have a number of well-known security vulnerabilities, not to mention that some of their “frameworks” allow SQL injection to this day.

IMO we need a second wave of commoditization of the web for non-technical users. Not sure there are technical stacks that do this perfectly but Erlang / Elixir are very close – although the BEAM doesn’t support sandboxing and built-in rate-limiting and/or slices of computing resources (that can depend on which user is on which paid plan, for example).

And websites die or get removed from Google’s index every day. That definitely wasn’t sir Tim Berners-Lee’s idea for the web and he said as much many times.

The average website needs to become very lean and mean if we want not to end up with the big 5 corporations hosting all the internet (which many people like myself would work against with all our will and skills… if we had the free time, or were paid for it).

Which brings us to…

That’s very true. I personally I’m unwilling to participate there though. The JS ecosystem is still juvenile at best – the committee cannot even agree on a standard library – and my time is better spent with smart people recognizing where evolution is needed.

1
Post #18
Kabie

Kabie

Here is another forum with GraphQL:

0
Post #19
jeramyRR

jeramyRR

Whatever happened to Firestorm?

3
Post #20