I’ve compared and read about openCloud and their new approach to using one binary for everything, and writing everything in Go language, but since the software is still very young and not production ready for at least a few years to come, I’d like to hear what NextCloud’s hopes are for switching their codebase to something faster than a LAMP stack and what the roadmap might look like.
It was started by ownCloud nearly 5 years ago:
So then, total time to put it in production when you start from 0 is 8-10 years?
1 Like
Did you hear/read anything indicating that NC was switching away from PHP?!?
Well, the rest of LAMP (aka Linux, Apache, MySQL), you can right now choose according to your personal wishes. I am pretty sure, you could use nginx with php-fpm and SQLite wich is definitvely no more LAMP. Put it on Mac and you are almost completely away from LAMP 
.
3 Likes
Considering the world of PHP applications written around NextCloud, this would be really astonishing. PHP is improving its performance with each new version. There are solutions to make it faster (opcache, opcache JIT), there are strategies also to improve FPM (preloading). There are also interesting projects that would need to be really studied and tested (RoadRunner).
But even so, the main work to do is to improve the way external queries (SQL, LDAP…). Changing the language won’t improve this. And considering what i’ve seen, there are a lot of queries to improve in NextCloud that will make it faster than changing the server language.
1 Like
For talk there is the high performance backend:
and for the notifications a push service:
These are server-side and not php.
I don’t know if there are other parts that might be improved in a similar way without rewriting everything.
Ahhhh… well… not really. The notify_push is not about Nextcloud notifications actually but to allow for arbitrary UnifiedPush messages to be sent out (not only for NC but any app might use it). E.g. the DAV team tries to integrate DAVx5 in a live manner that updates the contacts on mobile phones almost-live.
But it is not about the typical messages (“User X modified a shared file”) in NC. But still, it is non-PHP.
Chris
Nope, notify_push has nothing todo with unified push. It is actually used for notifications, on the web at least. It removes the burden to regularly poll for notifications but uses a websocket connection to inform clients about new notifications.
But it has nothing todo with push notification on mobile clients.
2 Likes
It’s also used by desktop clients, for the MacOs/Windows/Linux files synchronisations. Instead of requiring each 30s if “something has changed”, notify_push inform the client only when someting in ths files or the folders (from the user scope of synchronisation) has changed.
1 Like
Instead of constantly using PROPFIND to check for changes, an additional background service could monitor the file system in real time and notify the client through a separate port when something has changed.
This would reduce server load and significantly speed up response times — as a complement to the existing WebDAV model with PROPFIND.
Could such an approach be considered?
Hi, I think such an approach is already possible by using the notify push app: GitHub - nextcloud/notify_push: Update notifications for nextcloud clients
1 Like
I think the original poster has a valid point.
In the 1980s, BASIC was a widely used language — simple, accessible, and found everywhere. But as more powerful and better-structured languages like C and later Java emerged, BASIC was gradually displaced. Many developers who focused only on BASIC for too long eventually struggled to keep up.
Something similar could happen to PHP. While the language has matured — with FPM, OPCache, and various frameworks improving performance and structure — it’s still based on the LAMP stack, which originates from the 1990s.
Today, new developers are learning modern languages like Rust or Go from the start, because they’re easier to test, scale, and secure. And we can already see this trend: new projects like Immich, Photoprism, or Seafile deliberately choose modern backends, because they allow for better performance, concurrency, and security.
I don’t think a full rewrite is always necessary, but strategically opening up to modern architectures — e.g. by adding complementary services written in Rust or Go — could be a meaningful and future-proof step.
Because in tech, staying still means falling behind — just like BASIC showed us back then.
2 Likes
And that is exactly the purpose of the ExApps feature available since roughly 1 year. You can run arbitrary containers as part of a NC installation (containerization seems the most robust way to handle all the various dependencies of the various languages and stuff).
So, we are not going PHP-only but the core will be in PHP I guess for quite some time.
BTW: Adding plugins in other languages might be a bit of a burden, here PHP’s interpreted (and thus slightly slower) language helps.
But as already stated earlier: Just by going with a newer language does not make the core significantly better. See owncloud: dis it start to dominate the market after the migration? No, not really. So, a change of language is by far no guarantee to success. So, let’s keep it that way and use ExApps if we need/want to.
Chris
1 Like
Nextcloud in its core components and standard application is about 700 000 PHP lines of code. Some are comments, but some are the results of large history and modifications. I’m still far from sure that this is probably not the main priority of Nextcloud strategic heads.
- Concerning the Basic, there is probably as many differences from the good old Basic from our first computers and the Visual Basic that is still working in MS Office, that from the old PHP and the recent 8.x PHP.
- We need to consider also the investment of developers in Nextcloud Framework, the existing apps.
- Considering the new languages, if there would be a choice, it would probably be Rust. Notify_push was partially written in that langage and Rust is on a energetic point of view (that will be taken in account in the near future for large organisation), much better than Go.
1 Like
There was a longer discussion on the bug tracker at the time ownCloud announced the rewriting:
If the rewriting of ownCloud was not convincing enough, what else would be needed?
I once watched an interview. Unfortunately, I can’t remember the source. In the interview, Frank Karlitschek pointed out the advantages of PHP in Nextcloud. Among other advantages (and perhaps also disadvantages), he stated that one advantage of PHP is the fact that the actions in PHP are quite independent actions, so that high scalability is possible.
I’m not a developer, but by reading some of the statements here, one might get the impression that Nextcloud is written in some obscure and long dead programming language that only two people on Earth still know how to work with.
So, I have two questions for the Go and Rust missionaries in this thread:
-
Could you explain why Nextcloud is by far the most complete solution out there, with the biggest ecosystem of apps, extensions, and integrations of all comparable products, despite supposedly having an outdated and obsolete tech stack with which seemingly no one can or wants to work with anymore, while OCIS/OpenCloud doesn’t even have a calendar or contacts app yet?
-
Would you realistically be able to contribute to developeent if there were a full rewrite, while you can’t contribute now because you don’t know PHP? That was a rhetorical question.
5 Likes
I have no support/technical question and have seen the support category. (Be aware that direct support questions will be deleted.)
on
Which general topic do you have
Wouldn’t a complete rewrite into a faster programming language be preferable?
No need to reinvent anything, for such cases where pure file sync is enough and it is just about that performance, you should take a look at syncthing:
About software rewrites, you have already started a topic:
1 Like