Modernize the IPS apps for IPS 5

[KT Walrus]

I'd like to see serious consideration of changing the way IPS apps are implemented/deployed in IPS 5.

The PHP code should only be used for the UI and not for implementing the business logic for the app (including direct access to the database). IPS could re-implement the apps that it sells (including core, forums, blogs, commerce, etc.) in Go instead of PHP. The PHP code would still be used for output of the HTML, but would use a REST API to retrieve/update the database using a Go server that only serves a single app's backend services.

The Go app could be distributed in a docker container where the Go app has been statically compiled and can be configured by the user for database access and an authorization API for the PHP code to use.

Any third party apps could be coded as PHP for UI and Go server in a container, just like the IPS apps would be coded. Certain core services like authentication/sessions/permissions would need to be provided in Go libraries that could be directly included in the third party apps. Plugins and hooks could still be supported in the PHP side, but would not be able to hook directly into the Go app server so would probably be limited to UI hooks or changing REST API calls to the backend Go services.

The Go containers should easily support high availability by allowing multiple instances of the containers that implement the backend services (like Docker/Kubernetes load balanced/HA services).

Such an architecture could scale infinitely if an installation were deployed using one of the container orchestration products like Docker's Swarm Mode or Kubernetes.

[Dan C]

I've actually done some evangelizing for golang It's really useful for writing REST APIs and InfluxDB is a godsend for writing monitoring tools.  Having said that, adding another language and all its tools to the IPS ecosystem doesn't automatically make it more "modern."  And it doesn't stop there, either.   If we're going to write things in Go, why not Rust or Erlang or Haskell?   What about the next fad language that becomes the flavor of the year?

Your approach also has several drawbacks.   For starters, very few commercial hosting companies support Go today.   Or probably ever will.   So suddenly, you're forcing people into managing cloud servers on AWS or Google Cloud and managing servers is the last thing a lot of us want to do.

Secondly, forcing Docker on people adds a layer of complexity that's very much unwelcome in deploying small, simple apps.

Finally, there's nothing wrong with the MVC model that IPS uses today.   The code is clean, easy to read and understand and most of all, dead simple to extend.  

My only gripe with Invision is they keep ripping features out of the suite.

[Colonel_mortis]

As much as I would absolutely love IPS to switch to a better language, like Go, the big benefit of PHP is that every webhost supports PHP, but very few will support any compiled languages like Go. While many more technical users are running on a VPS, there are a lot of people still using shared or managed hosting, and I would be quite surprised if IPS dropped support for them any time soon. Perhaps if CiC became much more reasonably priced there could be an argument for it, but it would still cause a lot of complaints I expect.

If they did switch language though, and go through the whole process of retraining their staff, I don't see any reason to stick with PHP for any part of it - if you're going to do a service-oriented architecture like that, you might as well do the front end using a framework like react or angular, and just do an API backend.

Again, I would really love it if this did happen, but it seems pretty unlikely to me.

[HeadStand]

5 hours ago, KT Walrus said:

Plugins and hooks could still be supported in the PHP side, but would not be able to hook directly into the Go app server so would probably be limited to UI hooks or changing REST API calls to the backend Go services

Congratulations! You've just murdered a large number of sites that rely on plugins to function. 

Very very few of my clients are able to achieve their goals without overriding some of the core code. This approach would make the platform useless for many current customers. 

[Matt]

While we have discussed making a future version essentially an API back-end, it's not something that will happen in the medium term.

Invision Community 5 will overhaul several areas of code that we've labelled for refactoring for a while, but we're not going to scrap all our existing technology and start over. No one wants to wait another 18 months for a new version with the same features as they've already got with the added bonus it's using a cool framework or technology.

Most of our customers want value in terms of growing their community, they are not overly concerned with how the magic/code works.