Site Architecture

[thequbit]

There are, in my opinion, three methods to split up the "functions" of a modern website:

• Everything is a GET or a POST, and all content is rendered on the server.
  • This uses some kind of template language embedded in html that is populated on the server request.
  • POSTS are done to actual end-points and a page is returned ( super old-school baby! )
• "Single Page" Javascripty website ( such as Angular ) where everything (GET, POST, PUT, DELETE) is done via REST
  • This is really nice because there is complete separation from the back-end developers and the front-end developers, and only documentation bridges them
• GET is rendered on the server, but POST, PUT, DELETE is done via REST
  • Again, a templating language is used for GET pages, but all create, update, and delete functions are done via REST
  • This is nice because pages are easily indexable via search engines without the need for other ( in my opinion, unnecessary and complicated ) tools that pre-render your site for search-engine crawlers.

I've done one of each, and they all have their positives and negatives. For a rather large project I'm working on now we actually did a combination of 2 and 3 above. For the "administration" site, it's all angular. For the "web-facing" site it's option 3 above. We needed to make sure we were being indexed correctly, and didn't have the time/money/kills to pull a tool in place to make an angular app index correctly.

My vote is option 3 above. It is an okay division of labor, because the "back-end dev" is still just providing the 'objects' to the templated page, and the "front-end dev" can rock and roll with the data. Additionally, once the GET page is rendered, there is still plenty of fancy-dancy Javascript to write to do all the PUT, POST, DELETE stuff.

@GabeIsman @melodykramer Thoughts?

[melodykramer]

That sounds reasonable to me. I have to admit, I'm less knowledgable about this and trust you.

[GabeIsman]

I tend to prefer option 2 (single page app) pretty much always, because I think that it is the best possible user experience. I also think that it provides some very nice client/server separation bonuses, and adds a good deal of flexibility in choosing the right tools for each respective job. It also allows total separation of front-end and back-end development, and each can proceed in whatever order makes the most sense.

I don't think the indexing issue should be a showstopper, personally. The redirect crawler requests to a headless browser setup seems to work pretty well (reference: https://cdnjs.com/libraries/backbone.js/tutorials/seo-for-single-page-apps). Also, I'm pretty sure that Google actually downloads pages and runs javascript before parsing the DOM, I think they just aren't very public about it since they don't want people to rely on it (I have an entirely client-rendered site and Google's Webmaster Tools shows a screenshot of the fully-rendered page).

There is a fourth option which is the best of in terms of pure UX, which is having templates that can be rendered by either the client or the server. In this setup the initial page is always rendered by the server (so the user probably sees it faster), and all subsequent pages are rendered by the client (so navigation feels faster). This requires a couple of things which can add to development complexity:

1) The data required to render a view has to be available in the same form on both the client and the server. This almost certainly entails a pretty robust data-loading architecture.

2) There has to be a shared template language (not that bad, many template languages compile to/can be inflated by different languages).

3) The client side javascript has to know the difference, and behave correctly, based on whether it is an initial page load (no rendering) or a client navigate.

So my preference is for option 2 or option 4, but option 3 would also be fine (and provides some benefits that you didn't mention, such as easier pre-server caching a la varnish).

One possible compromise would be to go with option 3, but use a template language that can be rendered by both python and javascript. That we down the road we could much more easily turn this into a SPA without the added friction of rewriting all our templates.

[thequbit]

My Thoughts on your thoughts

I tend to prefer option 2 (single page app) pretty much always, because I think that it is the best possible user experience.

100% agree - max fast

I also think that it provides some very nice client/server separation bonuses, and adds a good deal of flexibility in choosing the right tools for each respective job.

mmhmm ... which has worked out very well for me in the past when doing other "large" sites. Coordinate what end-points need to be available by what dates using github milestones/tickets, and then each "dev team" ( person ) can rock and roll without every being blocked by the other.

It also allows total separation of front-end and back-end development, and each can proceed in whatever order makes the most sense.

I like this point a lot. There are soooo many different technologies out there. Any each dev is going to have her/his favorites ... this allows each dev to work within the tech that they do best with.

don't think the indexing issue should be a showstopper, personally. The redirect crawler requests to a headless browser setup seems to work pretty well (reference: https://cdnjs.com/libraries/backbone.js/tutorials/seo-for-single-page-apps). Also, I'm pretty sure that Google actually downloads pages and runs javascript before parsing the DOM, I think they just aren't very public about it since they don't want people to rely on it (I have an entirely client-rendered site and Google's Webmaster Tools shows a screenshot of the fully-rendered page).

... I can't know all the things! This looks/sounds awesomesauce. We can cross this bridge later, but seems solvable.

Additional thoughts

Option 4 seems awesome on paper, but ( and mostly I'm saying this because I lack experience with this kind of implementation ) could be too complicated for our MVP. My vote at this point is option 2, and we keep back and front separate.

And yea, I always forget about varnish ... it's such a last minute deployment thing for me. Good point for sure.

Shall we say that Option 2 is what we'll be doing for this project?

[thequbit]

@GabeIsman if you're thinking option 2, what's your weapon of choice for 'single page' sites? Is it Angular? I've done one angular site before ... I'm not awesome at it, but I can javascript pretty good. Just need someone to bootstrap the project and then I can be a active contributor.

[GabeIsman]

I think option 2 is great. My only potential concern is that if we end up relying on me to build the entire front-end it might become tricky to balance that against the work I'm planning on Midas. That said, if you're going to feel comfortable writing javascript too, then this sounds awesome.

From my end, I'd feel confident reading and modifying the backend, but I've never worked with Python on a real project before, so I'll be slowed a little bit at first.

@thequbit as far as weapon of choice--I've mostly used Backbone in the past (much more of a 'hands-off' framework where you can kind of do whatever you want). I've been wanting to do a project in React though, so I wouldn't mind going with that here. I don't have much experience with Angular (skimmed the docs once, ha).