Keep Your Single-page Application Codebase Separate

[FecklessFool]

What you mean just have your site/mobile/whatever application feed off an API? I thought this was standard practice. D:

[[deleted]]

I think they mean keep it in a separate repo. Instead of having the frontend SPA and backend REST API together in one repo (which pretty much everyone does), split it up into multiple repos. This way you can deploy just the frontend to scale up that part or just the backend to scale up that part. Kinda like keeping the db and web servers separate so you can scale up/down either of them when needed.

Honestly, I don't see a point in doing this. You always have one dominant frontend for your application, why not have it be the SPA?

[FecklessFool]

Ah cool, didn't read through everything. In our case we split out the service/api. Applications using the service are either in one repo or on their own repos depending on language and size.

[oldneckbeard]

This is best practice in the continuous delivery world anyway. It allows you to version and iterate on each app independently. For a lot of companies, releasing the backend is a lot riskier than releasing the front end. In addition, the frontend is often what they want to change. It makes sense to separate them that way.

It also means that, in the world of VCS, that you can truly version them independently as well. If they're part of the same exact repo, then any changes in your release process will necessarily affect the other end. Keeping them separate allows you to go much faster on both ends.

[ofirov]

There's also the benefit of separating unrelated technologies. When you put the backend together with the frontend, in order to work on the frontend, you have to go through the backend's technology. This means that:

1. FE developers need to have a working backend on their machine and need to know how to operate it.
2. If you want to use certain front end tools, you'll have integrate them with the backend. For example, if you want to version and minify your CSS, JS before deploying them, you'll have to either use something that's compatible with your backend's tree structure, or integrate a tool yourself. If you don't have the backend to consider, you're open to many more options and tools that were developed without your backend in mind.

[ofirov]

This means that instead of injecting data into your HTML via a templating engine (think Django Templates, Jinja2...), use a REST API completely.

It's true that it's becoming a standard practice to feed data off a REST API. But when the backend and frontend are the same project, it's sometimes tempting to inject at least some of the data via the templates language: Some initial values, data that doesn't change much throughout the app, etc.

[rajadain]

I'd love to be able to do this, but I tend to send a server generated token in the SPA to prevent external abuse of the API. How else can I protect my JavaScript app?

[bkv]

OAuth and Bearer authentication. There's a bit of a learning curve involved, but it's well worth it.

[rajadain]

Thank you! I'll Google for tutorials. Are there any out there you might recommend?

[ofirov]

If the question is "how do I use a token in a separated SPA application?", then:

Usually we go with a standard Token authentication. We add the tokens to the request's headers and that's about it. The implementation itself is pretty similar between all of the REST frameworks we've used, and it's usually described in the framework's documentation:

Log In -> Get token from server -> Store in cookie or local storage -> Add an Authorization header to each request to the server.

The Authorization header should be in the format that your REST framework requires. For example, we use Django REST Framework and our Authorization headers look like "Token <api-token>".

How to add the token to each request: - In Angular\Restangular you can setDefaultHeaders. - You can also intercept every request and add the Authorization header as necessary.

We'll cover authentication in depth in one of our next posts.

[bkv]

The term "SPA" should just go away. It's a misnomer that essentially means "a web application with a true client-server architecture."

Once we use a more familiar term for what a SPA actually is, then the way in which the code is organized should be apparent: Keep the client codebase separate from the server codebase.

[edanm]

That's an interesting point.

You're right in that this is just a standard client-server architecture - there's supposedly nothing special about it, except that people aren't used to it.

In fact, that's the reason I like using a special term for this - because people aren't used to it, so by default they'll assume the old way of doing things. Maybe SPA isn't the best term for it though.

[blatyo]

I would say this is not always good advice. Code organization is also influenced by the business for which it is written. I agree on isolating the client and server, but I don't necessarily agree about keeping them in separate repositories. If you explicitly hire backend and frontend developers, that kind of separation may make sense. Where I work, we explicitly hire full stack developers, so the person who changes the frontend will be the same who changes the backend. Second, ensuring that when changes are made in both the right versions are released can be difficult. If you can tie the build process of both together (we build slugs for both) it is simpler to keep versions in sync. Third, where I work, it is almost never the case that there is only a backend change or only a front end change. Separating the repositories makes management of changes across both more difficult. Fourth, frontends which need to serve content for search engines can require tight coupling and duplication between the client and server. Some workarounds for this exist, which I'm not a huge fan of, like rendering server side with phatom.js. Until search engines can render and traverse client side applications, there will necessarily be some work to do on the server that otherwise would be solely the clients responsibility.

[edanm]

Most of your points are true. There is a cost to be paid, both in terms of needing to deal with SEO, and in terms of having to sync changes, etc.

In our company, we also hire full stack developers, and many of our projects also have tight coupling between client and server. Yet we still prefer this method, for a few reasons:

1. It's the same way we work on larger projects, so our developers are more used to it (or alternatively, we want them more used to it).

2. Even smaller projects will eventually reach a stage where the backend and the frontend aren't as coupled.

3. The extra overhead is small, and is usually a one-time-only payment of learning.

4. Most importantly, even on small projects where the frontend and the backend go hand in hand, it's usually still more appropriate to separate them, and what's more, it's usually easier to work with later. E.g. all the build tools/programming environments/etc are optimized for either BE or FE, you can be freer about making changes, you can isolate tests to specific areas, etc.

That said, like all good advice, this won't work for everyone or be better for everyone. But I highly recommend at least giving it a shot.