search

pump-io / pump.io

Social server with an ActivityStreams API
http://pump.io/
Apache License 2.0
2.22k stars 333 forks source link

Separate Web UI from API engine #1561

Open evanp opened 6 years ago

evanp commented 6 years ago

This is pretty out there, but: we could move our Web UI to a separate project that could be the front end for any ActivityPub server.

Our code for Web requests could then just load a shell that uses the Web UI, and the Web UI could figure out what it's supposed to show based on the URL.

This would reduce a lot of the complexity in the app.

strugee commented 6 years ago

I've thought about this too. Long-term I think we should offer three "products":

  1. Something like the current codebase
  2. Stripped-down server that doesn't include any of the web UI stuff, basically the API engine you're describing here, which would basically be a wrapper around
  3. libpumpio (or whatever), which other people could embed into their apps or whatever to do distribution
strugee commented 6 years ago

And I guess also 4. the web UI standalone, if we wanted to do strictly what you've suggested here

Serkan-devel commented 6 years ago

Could it still be layed on the main repository as submodules?

strugee commented 6 years ago

Good question. This is somewhat of a medium- to long-term thing so I don't know that anyone's been thinking about exactly how this would work. I will say that submodules are mediocre at best - they work for very specific usecases, but other than that they're... not so great. It might be that this is one of those usecases though.

ghost commented 6 years ago

Could be a microservices structure, an external package like pump.io-ui as dependencies of pump.io or a monorepo with yarn

Serkan-devel commented 6 years ago

the microservice variant sounds good

Serkan-devel commented 6 years ago

Maybe something like pump-qt, pump-gtk etc for the digferent UI implementations that may happen?

strugee commented 6 years ago

You can already build GTK+ or Qt clients using the API.