An open-source web platform for the new President of France

>Wow, the modern PHP community is on fire! I had no idea. I basically rage-quitted PHP years ago, after repeatedly inheriting a series of Wordpress wrecks.

There still are Wordpress wrecks, and will be until the end of time. But there's a lot of good PHP code being written now, it's going through somewhat of a renaissance. Lots of good work being done with Symfony.

>Just curious, how does a PHP application handle server side rendering? By shelling out to a headless browser? What if the content is so personalized that server side caching isn't helpful, is it still viable to SSR a React client?

I haven't done SSR for React with PHP, but this react library [0] runs v8js, so it's not as heavy as a headless browser. The Angular2 team is building SSR for PHP now but hasn't released it. From scanning the GitHub issues it looks like they're taking the same approach (v8js) [1].

[0] https://github.com/reactjs/react-php-v8js [1] https://github.com/angular/universal/issues/281

I assume given their setup that they were only using React for interactive components and the rendering / routing was done server side in good old PHP by their framework.

There are a few approaches, usually via a standalone node.js service. I've seen similar architectures for ruby and python web servers as well.

I'm working on a project now that uses airbnb's hypernova service[0] with a php client[1].

Edit: not suggesting this was used in this case, just that it's a viable option for react ssr + php.

[0] - https://github.com/airbnb/hypernova

[1] - https://github.com/wayfair/hypernova-php

>I basically rage-quitted PHP years ago, after repeatedly inheriting a series of Wordpress wrecks.

Every language can be abused - the degree to which it can be abused is an indicator of its power.

At my previous place of work, we used the V8js extension to fire up a V8 VM, send data to it and render react components to strings. Worked really well, especially with some caching in place.

Of course, we also moved to Amp and a PHP-cli-running-async-http-server model, so we can share the in memory extension, and did some cute stuff with Redis to get it running stupidly fast without memory leaks. Good fun really, PHP 7.1 is damned nice in a lot of ways, but annoying in others still.

server side rendering is the mess people will inherit in a few years.

I can already see the HN posts: "I rage-quit X because of all the mess I inherited where the developers didn't want to learn proper javascript, so they just added so much abstraction they had to use hacks to pre-render it on the server"

I don't follow. Server-side rendering did you mean rendering html? It would be the same as non-JS rendering engine framework the server side sends out the html after the template file is rendered on the server side.

Same here, I left PHP during the early 5.x releases. Unfortunately, I inherited some Symfony applications recently. Unfortunately, because the whole stack is terribly slow and held together by an insane amount of YAML and XML configuration files. Add "annotations" (that are parsed out of doc blocks and compiled into another bunch of PHP files) to the soup and party like it's 1998. That pile of classes you end up with will serve quite some traffic behind a good caching layer, typically in the shape of a well configured Varnish instance. Needless to say that runnig this on your own machine during development will not exactly give you the excitement of working on a fast, modern platform. Rest assured, "print_r() and die()" is still a thing.

Besides that, memory management is mediocre; just DON'T do long running processes with PHP. You want to enable a module? Good luck finding the right php.ini. Keeping a persistent connection pool to a database or similar is generally hard and intransparent, due to the fact that each instance serves exactly one request, but hey, at least PHP "automatically recovers" from errors...

I left for good.

PHP is becoming nicer and nicer over time :) . Perhaps would it be worth a new try?

In the project, we didn't use server-side rendering: what I meant in the article was that the basic HTML was a first version then replaced by React, on the client side. The React component has different code than what was rendered initially, but for our usage it's not an issue.

I'm sorry, the accounting is meant to be public, but I can't find it. It might be too early, or google is failing me.

On a related note, the total budget for the candidates had to be less than 17M€ all included before the first round (then they could spend 5.6M€ more for the second round). A lot of that goes into organizing rallies.

edit: I guess they are meant to be here http://www.cnccfp.fr/index.php?art=584

In a political movement, the main source of costs is the organization of the movement itself (members, committees, events). It is perfectly normal as it is the core of the party, but it is really difficult to decrease these costs. In classical parties, this organization required to have a physical place in thousands of cities in France.

What I meant in the article was that our budget was way smaller than the one of other parties. That is the reason why we relied mainly on Internet since the beginning to create committeess and organize events.

This being said, the "small" budget we had was not that small if you see it as an individual: we had several million euros coming from donations and loans. This was not enough to have physical places in France but it was largely enough to create a high-end platform instead.

Technically speaking, the hosting and the different services we use costed us around 8000 euros/month at the end of the campaign, including the DDoS attacks mitigation (which did indeed increase our costs). The website development itself is very difficult to estimate as it was made both by volunteers as me and by external companies.

I also would like to add that the cost of development would have been much higher if we had relied only on external companies. The flexibility required by a presidential campaign forced us several times to develop complete features in a few hours and that would have been difficult with a classical company only, requiring specific contract and limiting our possibilities. I think one of the reasons why the project went really well was because of the synchronization between motivated volunteers (highly flexible work time) and external companies (proper high-end quality code).

Kubernetes was the key part in our development process: it gave us the flexibility, stability and scalability required to handle million of users while still deploying multiple times per day.

At the beginning of the campaign, we had only one node in the cluster, as we thought it would be enough. However, while it was enough most of the time, it had issues under DDoS attacks: as the node was the only one, it was the master node of Kubernetes and when it overloaded, Kubernetes crashed.

To avoid this, we used three smaller nodes instead, to avoid having a node overloaded leading to the whole system crashing. Kubernetes handled the following attacks really well with this setup, and it did not cost more for us.

About the attacks: they threw more at us (XSS, SQL injections, etc.) but most of these attacks were still automated. Perhaps have they tried something even more subtle, but I doubt it: they prefered to hack emails :) .

I have to admit making the project open-source was a quite difficult decision: I really wanted it, but I also knew we would be potential targets of powerful organizations. We decided to do it because in the end, the argument you stated was stronger: open source does lead to more secure, stable and quality code, and this project showed it. Note also that we didn't advertise much on this project during the campaign, so perhaps was it not clear for potential hackers that the code was open.