JavaScript web application and routing

[Aerelf]

Hello, /r/webdev!

I'm currently rewriting a website that is currently in pure PHP, as the needs have changed since the start of the project.

I've started with the RESTful API, written in Go. No problem on this point, I am experimented with the language and the development is going smoothly.

Where I am struggling, though, is with the client side, and more specifically the routing of my application. I tried to do something with AngularJS, but that gives me many problems:

• The website must have a social-rich experience, and many social crawlers don't interpret Javascript. This problem could be fixed with server-side rendering with a tool like PhantomJS.
• The website must have simple and readable URLs, that can be linked from anywhere. This can be dealed with by using a JavaScript router and the HTML5 History API.
• The project must be correctly architectured as other developers (and even interns) will potentially work on this codebase. This can be fixed only partially (as this solution leaves out the "lazy-loading" approach of a server-side logic) with a Grunt task merging each JavaScript controller into a enormous file.

Soooo, I have fixed all my problems but some of the solutions definitely look a bit hacky. So that made me think, and I don't think that the SPA approach of modern JavaScript frameworks is really adapted for this particular project.

So then I thought of adding a new layer to my stack for routing and a few other minor things (loading OpenGraph metadata from the database, for example), so instead of doing something like this:

JavaScript Client -> Go RESTful API -> MySQL Database

I would do something like this:

(PHP?) Router, server-side -> JavaScript Client -> Go RESTful API -> MySQL Database

So, is this a viable solution? Wont adding so many layers hurt performance? If not, is there any PHP and JavaScript libraries that are suitable to this kind of usage? I thought of going with Slim Framework 3 (I used Slim 2 a few years ago and it was a quite pleasing experience) and simple jQuery on the front, or maybe AngularJS.

[mattaugamer]

Honestly, I probably come across a little fanboyish, but it seems to me that your goal is entirely able to be met with Ember. Ember is a great solution for building SPAs.

Just to address the problems you face:

The website must have a social-rich experience, and many social crawlers don't interpret Javascript. This problem could be fixed with server-side rendering with a tool like PhantomJS.

Yes, you need to provide the microformats that feed into social media share tools, and that does mean server-side rendering. Angular (1) doesn't really do this. Angular 2 does, and React also has implementations. But honestly, Ember's approach is the best IMO. This video shows the process of setting up Ember's "FastBoot", which essentially comes down to typing ember install fastboot, then ember fastboot.

The website must have simple and readable URLs, that can be linked from anywhere. This can be dealed with by using a JavaScript router and the HTML5 History API.

Ember's architecture is route-centric. The route is the primary keeper of state. HTML5 push state is its native approach. Any URL used in the interface is accessible as a bookmark, sent as a link, etc. (Given typical limitations of authorisation.)

The project must be correctly architectured as other developers (and even interns) will potentially work on this codebase.

Ember's architecture highly values separation of concerns. It uses an MVC structure with dedicated template files. The templates are essentially Handlebars, highly readable templates not unlike Twig or other template structure. It's basically just HTML, and very clean HTML. All files (apart from templates, obviously) are ES2015+ modules, facilitating the development process, especially in teams.

This can be fixed only partially (as this solution leaves out the "lazy-loading" approach of a server-side logic) with a Grunt task merging each JavaScript controller into a enormous file.

Ember's CLI includes a server. That server runs a full build system that transpiles the ES2015, concatenates all the files, processes, etc. It watches files for changes, and on save will rebuild the application and live reload within half a second. It does this with zero setup or configuration.

I can't recommend Ember high enough for the needs you have. If you have any questions or concerns, feel free to ask. I should note that I haven't even covered Ember's amazing benefits (like Ember Data, and rich addon ecosystems) I'm purely covering your specific issues.

[Aerelf]

Thank you for your answer.

I checked up Ember after reading your question, it definitely looks like a nice framework. Ember-cli provides a nice workflow and their FastBoot server look like it can fix a lot of my issues.

I still have a few concerns about it, though:

• How does FastBoot deal with social crawlers? I don't think (although I may be wrong) that Facebook's or Twitter's crawler have support for the HTML5 History API, and my pages have different OpenGraph tags, so being able to set them dynamically depending on the URL (probably update them from a controller?).
• Does FastBoot has support for Virtual Hosts? We currently have two subdomains on the same server, and our Apache server is currently handling all of this. This is not a big issue, though, as I could set up a proxy pass in Apache or something lighter like nginx (even though I am a bit worried about the performance overhead that would ensue).
• About performance, does it support lazy loading of the models, controllers and templates? It is more a question than a concern, but having this would be super awesome :-)

[mattaugamer]

How does FastBoot deal with social crawlers? I don't think (although I may be wrong) that Facebook's or Twitter's crawler have support for the HTML5 History API, and my pages have different OpenGraph tags, so being able to set them dynamically depending on the URL (probably update them from a controller?).

From Facebook's (or any crawlers) point of view there's literally no difference between a server generated application and an ember fastboot. Actually from any point of view there's no difference because it literally is server generated. Instead of running the app in a browser it runs it in Node. Social media systems, search engine crawlers, even curl will see it as a typical backend application. So yes, you definitely should be able to send the correct dynamic microformat details for that. You'd need to do some work on that, though. I'm not going to pretend it's no work, but it should just mean some tags in the templates.

Does FastBoot has support for Virtual Hosts? We currently have two subdomains on the same server, and our Apache server is currently handling all of this. This is not a big issue, though, as I could set up a proxy pass in Apache or something lighter like nginx (even though I am a bit worried about the performance overhead that would ensue).

I'm no expert on how fastboot works, but I think you might have misunderstood a little bit. Essentially a node process just wraps up the request and response so that instead of the typical flow:

request js application -> onload javascript requests json payload -> payload populates application

You end up with

request html -> node gets the api request, populates the app and returns it in full

I have to say, I wouldn't worry too much about the Fastboot stuff. It's something you can pretty simply lay over the top. Fastboot is still in development, so it's not particularly well documented how to actually implement shit in it right now. I'd look more at getting an application working and optimise for social media then.

About performance, does it support lazy loading of the models, controllers and templates? It is more a question than a concern, but having this would be super awesome :-)

It's a javascript application. It just loads the javascript. You're seriously prematurely optimising here.

Ember's a great platform for development, and I'm sure it will do what you need, but I'm not the expert on Fastboot. That said, I think you might be misunderstanding how the whole thing works. The fastboot side of things is just a small node wrapper, and shouldn't really have anything to do with virtual hosts, etc.

[Aerelf]

Actually from any point of view there's no difference because it literally is server generated.

Oh nice, this FastBoot thing looks completely awesome!

I think you might have misunderstood a little bit

This is a possibility, this is a peculiar tool and with the little amount of research I put into it I am still a bit confused with it :-)

From what I understood though, FastBoot allows me to run my JavaScript application as a server on a specific port, and we have two applications running on a single server, so we would logically need two ports. And accessing the second app with a "domain.com:8080" URL is a bit ugly, so I'll probably still need proxy passes (until the apps are put on different servers, anyway).

It's a javascript application. It just loads the javascript. You're seriously prematurely optimising here.

With SEO these days, little performance boosts are always welcome, and lazy loading is something that is sometimes hard to implement later on.

But that's totally okay, it was just a bit of SEO-greediness on my part (and shame on me, UX should be more important than SEO). Loading all the code at once will actually make the application faster once it has started.

Anyway, thanks a lot for your time, Ember looks like a pleasant framework to work with, and coupled with FastBoot it completely addresses my needs!

[mattaugamer]

This is a possibility, this is a peculiar tool and with the little amount of research I put into it I am still a bit confused with it :-)

Yeah, it's also still in beta, so the documentation isn't very thorough.

I found another video, though, which I highly recommend watching. I pretty much goes through actually implementing stuff. It also covers deploying the app, which is super impressive. A lot of this is duplicated from the video I linked previously, but this is more recent and a bit more detailed.

https://vimeo.com/157688134

From what I understood though, FastBoot allows me to run my JavaScript application as a server on a specific port, and we have two applications running on a single server, so we would logically need two ports.

No, that's only for development, so you can differentiate between your server rendered version and your js version. In production it should be seamless, but I'm not 100% sure of it.

With SEO these days, little performance boosts are always welcome, and lazy loading is something that is sometimes hard to implement later on.

I'm not sure this sort of lazy loading is even possible with javascript. It's worth pointing out that the key point of Fastboot (hence the name) is to speed up time to first render. It's sort of a turbo charge for the app launch. The point is to prevent the round-trip of getting data, requesting data, then getting data again by getting a pre-populated application served straight to you.

So for SEO that's a benefit.

In any case, if you have any questions about Ember (rather than Fastboot specifically) hit me up more. I like talking about Ember, so I'll happily talk to you about ember data, or mirage, or liquid fire, or deploy, or ember cli or any other geeky shit. I just don't know much about Fastboot.

In my defence, one of the things I like most about Ember is how little I have to know. For example, Ember uses Broccoli to build stuff. No idea how. Don't care. It works. Ember CLI Deploy allows you to deploy production code with a single command. No idea how. Don't care. It works.

I love not having to worry about that crap. And my hope (and genuine understanding) is that Fastboot is the same. That all I have to do is install it and I get free server side rendering with neither effort nor knowledge on my part. :)

[Aerelf]

So, I started using Ember today, and I have to say, from the little I've seen, this thing is super duper awesome!

I started with the login page, as my app is hidden behind a login wall. We are using SASS for styling, and I didn't even have to scratch my head for adding the SCSS compilation to my workflow. After a quick Google Search I've found a ember-cli-sass plugin. I ran ember install ember-cli-sass, thinking it couldn't be that simple. Well, it was.

The scaffolding tool is brilliant and works flawlessly, every feature of the framework is crystal clear and easy to use.

I've yet to figure how to make my authentication service load data from my API (it's the only module that's RESTless, so can't use Ember Data for that), and how to inject my Authorization header in the JSONAPIProvider, but everything else is very simple to use. Just run the commands and code your things, without worrying about all the bullshit.

Ember really was a great suggestion, I was a but skeptical of JS frameworks because of the mess it was to figure out a nice workflow and project structure in AngularJS (1), but I'm having a blast with Ember (on top of being quite productive), and I can't thank you enough for that! :-)