I have a Back-end web application that provides me with custom API endpoints (Java - Spring). I like to keep everything separate. one API application that provides everything else remotely. My question is: What is the best practice to start a new Front-end project that connects to my API?
Requirements:
The Front-end project should be on a different server
The Front-end project should support routing, meaning I will have full control regarding the /paths. so no .extensions at the end.
SEO is very important in this specific case.
My preference is to go with React.js but I have doubts regarding SEO because the project I want to migrate from is WordPress (up and running with a good SEO performance).
I wish that I can find a simple solution with pure HTML, CSS and some kind of JavaScript.
Thank you.
React isn't actually bad for SEO. So long as you're taking the proper steps to ensure that the page load time isn't bad. If the site that you're migrating is massive, make sure you're lazy loading.
If you have doubts that Google or other search engines will render the js, then I suggest going with Nextjs like Rakesh K mentioned.
There's also nothing wrong with recreating the site with a templating language like Handlebars, then rendering it on an Express server, or whatever suits you. Just including this option in case you don't know React, and don't want to have to learn it.
I got confuse while searching top JS backend framework then I found NextJS is one of the top list, I thought nextjs is just a simplify of CRA and still need like nodejs as the backend. Back to my confusion, so when we normally create a full JS app we will need frontend and backend tech like (nodejs + reactjs) so with this nextjs we can make a app just with nextjs ? **sorry for my bad English
Simply said, NextJS is basically React on wheels and has NodeJS built-in. It has lots of other features built-in so you need almost zero-configuration to build a full-stack app.
If you have 10 minutes to spare, take a look at this video
Essentially NextJS is a full-stack framework. Which means that developers can write both front-end and back-end code in a single environment. It can provide multiple benefits among various use cases. Which can be things like seo optimization, image optimization or quickly switching between different rendering methods (SSR, CSR, ISR or SSG).
As for your question "Can we make an app just with nextjs ?", you certainly can but it depends heavily on what type your app is.
We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.
This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.
We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.
This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.
UPDATE 17 July 2013
Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.
The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.
UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.
Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.
You have a large list of features that will benefit you outside of client-side routing:
two-way binding
templating
currency formatting
pluralization
reusable controls
RESTful api handling
AJAX handling
modularization
dependency injection
It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".
If it fits your project, use it.
I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.
Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Each of these applications has it's own local routing mappings between states in the application.
I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.
Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.
In response to your question:
Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.
I also support the idea:
What’s the difference between a project and an app? An app is a Web
application that does something – e.g., a Weblog system, a database of
public records or a simple poll app. A project is a collection of
configuration and apps for a particular website. A project can contain
multiple apps. An app can be in multiple projects.
If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.
Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.
Javascript namespacing allows you to keep your code separate and manageable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
And in a script tag after your other scripts are loaded
<script>
myCo.init();
</script>
The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).
Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.
I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.
Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.
Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.
Links:
https://vuejs.org/
http://aurelia.io/
Stumbled accross NextJS in npm and tried it out. Look pretty good and relatively easy to use. However, one thing about it is still not clear to me:
Suppose I want to have also have a NodeJS (or whatever) api server in complement with the server side rendering that NextJS offers. Do I need 2 server then? For example:
Also is NextJS just a rendering server (which can render React components and creates HTML) or something else/more?
You can definitely use the same server to implement your api.
On official documentation page about Custom server and routing there are examples of integrating with popular node frameworks like express or koa - so you can use them for regular purposes.
What about nextjs itself - like it's said on official documentation page:
Next.js is a minimalistic framework for server-rendered React
applications.
So it has not only capabilities of server side rendering, but also routing (including client one), css-in-js setup and so on.
Our entire codebase is built on just express, we want to build it out and in the process convert it to a single page application. As of now I am opposed to rewriting the code to work with a framework like Angular, or React, to accomplish this.
Thanks for reading.
Are you sure a SPA web application is what you really want to achieve?
If you are, then the answer is Yes: you don't need a framework for any SPA or any other frontend purposes.
A SPA usually consists of following parts:
Client side routing (eg HTML history mode)
Client side templating (see Smashing Magazine article for some examples)
Retrieving the data (eg via Fetch API or Axios
So, using these technologies, regardless of your backend technology, you can create a SPA with Vanilla JS. Actually, what you use at your backend has little to no affect on your SPA.
However, depending on how big your application is or how much features you need, you might end up using one. Frontend frameworks are designed to make your life easier.
If you are looking for a framework with an easy learning curve, I strongly suggest Vue.js. You can even get started without installing or transpiling anything locally.
yes, you can - depending on the complexity of your application you may end up transitioning to React, Angular, or another frontend framework in the future depending on your needs.
here are some resources:
https://tutorialzine.com/2015/02/single-page-app-without-a-framework
Todo in different frameworks (for comparison):
http://todomvc.com/
Angular vs Vue vs React:
https://medium.com/unicorn-supplies/angular-vs-react-vs-vue-a-2017-comparison-c5c52d620176
If you're going for a real single page application you should be able to continue to use express. You'll find yourself jumping through some hoops though and using React/Angular would be a better approach because of how you could move forward with it in the future with no limitations.