Architecture

[noandrea]

the architecture proposed (enrico) is composed of 2 elements

• directus + mysql (for the backend)
• nodejs (for the frontend)

since directus requires a web server + php runtime (1), and since nodejs (2) provides is own http layer, we have two services that must be reachable, and since they cannot listen on the same tcp port we have two options:

• no reverse proxy

using this solution the customer will have two urls to manage, for example: http://example.com (frontend) http://example.com:8080 (backend)

this solution is a bad idea for so many reason that it's listed only to show how not to do stuff.

• reverse proxy

so the webserver + php will also have to work as a reverse proxy for the nodejs component, this is an example of nginx configuration on how we can make this happen:

server{
    listen 443 ssl; # because, you know, letsencrypt and all...
    server_name example.com;

    location /admin {
        # here it goes the directus part
        # with it's rewrite rules
    }

    location / {
        # here it is the reverse proxy configuration for node js
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://localhost:8080/;
    }
}

ATTENTION! this kind of setup will require some testing since there are going to be a lot of routing issues

[noandrea]

I'm not sure (@Muchtin maybe you can share your opinion) that this setup is easily achievable with a shared hosting.

I find the architecture quite complex for the scope of the websites in object, having 2 web server to serve what are going to be mostly quasi-static websites is overkill. therefore, there must be significant benefits to choose this layout. (@enrico?, @dennis?)

if the serverside rendering with nodejs is paramount, I will suggest to look into headless cms written in nodejs to get rid of the php part.

[ricricucit]

Choosing nodeJS CMS (@noandrea @dennisniederrainer did you find one?) would change too much the current habits of welance devs, so if we decide to go this road We'd need @noandrea or @dennisniederrainer to be responsible for this change and keep following this project in the future. This means explaining/teaching other developers how nodejs and the chosen CMS works, sometimes spending non-paid efforts. If you can find a nodejs CMS and the above future tasks work for you, we can definitely consider this. Otherwise I'd stick to the plan and setup this complex architecture which hopefully will require a lot of efforts just this first time.

@Muchtin : do you find this too complex? Do you see big problems?

[ricricucit]

If we want to switch CMS...probably this would be the best option (but I've never looked into it). @noandrea @dennisniederrainer could you please give it a try as you did with directus? @Muchtin could you please check if the requirements could match possible nodejs hosting plans you might have in mind?

[Muchtin]

@noandrea @ricricucit this setup is not possible with any shared hoster out there. You can't do things like reverse proxys on there systems. If this should work you need a server where you have root. A cheap VPS for every customer and a chef/puppet/ansible/baseimage/whatever to deploy the basesystem.

[ricricucit]

@Muchtin what about going full JS with KeystoneJS (remove PHP), would that simplify things?

[Muchtin]

@ricricucit going away from everything that needs dependencies is the best way for shared hostig. I you have luck you get composer on some servers but nothing more. If you can bundle you dependencies fix in your poject that you are fine with JS

[noandrea]

well, what about removing the nodejs part? as I understand it you can also very well create a project with angular/react/vue/aurelia as frontend and directus as backend, therefore the nodejs server side rendering is not necessary

[noandrea]

also, @ricricucit about choosing a nodeJS CMS, I didn't search for it and I do not recommend to do such thing, see http://harmful.cat-v.org/software/node.js https://medium.com/@richardeng/the-javascript-phenomenon-is-a-mass-psychosis-57adebb09359 So the server side nodeJS javascript thing, is something that you like to have or is a fundamental block of the development that cannot be replaced and so makes all the decision go around it?

[ricricucit]

Going on with this conversation on the phone, me and @noandrea are now looking at things like PhantomJS (which I already use to generate static version of simple websites) and Nuxt (a way to run VueJS apps via nodejs) ...but seems like nodeJS is going to be mandatory.

Something we can consider ( @philipphentschel @Muchtin ) could also be something like SEO.js which would solve our problem using it as an external service....but costs. What we could do is get a licence for welance...and when it grows, instead of paying more...we can build our own. This would give us the option of not worrying about this...for now.

[noandrea]

recap: after the mentioned call with @ricricucit the reason for the node.js instance is related to the SEO component of the website, basically if an application is rendered trough javascript using modern frameworks (angular/react/vue/mithrill/etc..) a crawler will index what is likely to be a blank page. having a node.js instance that render the page on the server side will provide an "already rendered" page and therefore the website will be indexed correctly.

I've looked up which are the possible solutions and here is an overview of what I've found

1. do nothing

google crawler as 2015 is able to render javascript so it is able to index the page.
pros: there is nothing to do :)
cons: google may be able to index correctly a page, but other crawler most likely can't, so probably not a very good idea.

2. node.js server

this is the solution proposed by @ricricucit
pros: very little to nothing to do on the developer side, website indexed correctly by everybody
cons: more complicated architecture, and as @Muchtin points out requires a VPS for each customer (or a shared one, but [insert legal issues here])

3. prerender a static version of the website

this is what github pages do.
pros: nothing to do for the developer while building a website
cons: the pre rendering must be engineered, developed and maintained and it may be also an issue in term of shared hosting since it is required to launch commands from php (in case of directus) that may not be possible in a shared hosting environment (amiright @Muchtin ?). also it may became an issue with more dynamic websites where a lot of pages have to be pre rendered

4. external service

like SEO.js or prerender.io, this services basically do the pre rendering as in 3., you just pay somebody to it, they will keep taking snapshots of the website and serve them
pros: very little to nothing to do on the developer side
cons: it costs money

5. switch everything to node.js

that's it, all the development will be done on node.js. this one was mentioned so I put it on the list, but I am confident that eventually a general solution will be found globally, and (as I may have mentioned before :) I don't think is a strategically sound solution.

6. don't use SPA frameworks

I know that after you read the title of this option you are a little upset, probably swearing at me, but I have actually found people advocating for it for website that are not web applications so I've added it here, you know, to be scrupulous. let's stay friend.

having seen the issue and after searching for solutions looks like that the common accepted solution at the present time is the number 2.

[ricricucit]

Thanks for this!

Point 6, as you guessed, is not an option. If you build modern websites you absolutely need a SPA. This is not me wanting to be fancy, but jquery not be able to satisfy modern clients needs (for websites and web apps)...and since this is my domain of expertise I can argument this with at least a 150 pros about that...and a blog post which I will write soon enough. 😉

...and number 2 is what I've proposed, so I'm happy you see that as doable (even tho it's not the best solution)! 😉

Hope we can make it!

[noandrea]

@ricricucit yes, I pointed out the 6 is not an option, and for the 2 I've just stated that is the common solution (still not a very good one :)

to implement the solution number 2 we need a VPS (as pointed out by @Muchtin) solution + mail management that is under 9.95€/M

for the VPS the google search "vps deutschland" gives this results:

• https://www.hetzner.de/en/hosting/produktmatrix_vserver/vserver-produktmatrix (~5€/m)
• https://schnellno.de/cart.php?gid=1 (4-7€/m)

for the email system probably the most affordable is zoho email:

• https://www.zoho.eu/ (25 accounts free, or $2 user/month)

but I've never used nor those vps services nor the zoho email, have you?

[ricricucit]

My 2 cents: Could be interesting to try to also find something übersecure for both hosting and email (smt like proton?).

To have a good selling point for clients, when proposing them to migrate. ...But I'm sure @Muchtin input will help us solve this issues. 😉

[noandrea]

I've updated the schema of the architecture with a little more details

[ricricucit]

Cool. We also need npm and webpack as software for CI https://github.com/welance/welance-be/issues/1#issue-220134161

[ricricucit]

Ladies(not) and gentlemen, We reached a conclusion talking with @Muchtin and @philipphentschel.

We will be hosting on our own VPS (option nr. 2, with @noandrea's proposed architecture) on digitalocean (which we already have accounts for).

NOTE: For clients that won't agree in hosting with us, we will offer option nr. 3 (pre-rendering), ideally pre-rendering on demand with scripts or some sort of action required by the client (eg. button "render application for SEO").

Feel free to re-open this issue if you find that this solution won't work for any reason.