So, I've been fiddle:ing with some isomorphic React + Flux lately and have found some concepts quite confusing to be honest. I've been looking into best practices about how to structure isomorphic apps and are looking for advice.
Suppose you are creating a webapp as well as a mobile app backed by the same REST API. Do you bundle your REST API together with the webapp? I've seen people advocating both bundling and having a separate codebase for the REST API.
Any advice or suggested reading is appreciated!
Fluxible (atleast from the examples) does advocate using the service layer inside the application calling it directly from the server and via xhr from the client without duplicating the code
https://github.com/gpbl/isomorphic500/blob/master/src/app.js
This is an example I followed religiously while building the isomorphic app
The idea is very simple. Let's assume you have SPA and a backend wich provides REST API.
SPA (in browser) <====> Backend REST API
in isomorphic case, it is absolutely the same, except you will run your SPA on the server too.
So, it will work like that:
SPA (in browser) <====> Backend REST API
SPA (on server) <====> Backend REST API
If you have a mobile app then it will be:
SPA (in browser) <====> Backend REST API
SPA (on server) <====> Backend REST API
Mobile app <====> Backend REST API
Here is a real isomorphic production application opened by us to the community - https://github.com/WebbyLab/itsquiz-wall . You can just clone it and run.
Here is my post which describes all the ideas behind the app in details.
Let's see if I can help you.
Please keep in mind that Isomorphic Javascript is quite new and it is hard to find clear definitions for every use case.
By definition, if you create a RESTful application you should have a clear separation between server and client:
"A uniform interface separates clients from servers. This separation
of concerns means that, for example, clients are not concerned with
data storage, which remains internal to each server, so that the
portability of client code is improved. Servers are not concerned with
the user interface or user state, so that servers can be simpler and
more scalable. Servers and clients may also be replaced and developed
independently, as long as the interface between them is not altered."
Regarding isomorphic applications, the main benefits are:
Not having a blank page when the user first enter the site (points for UX)
Therefore it is SEO friendly
And you can share one logic between server/client (for example regarding React Components)
This means you should deliver rendered React Components from the server to the client when the user first enters a URL. After that you will keep using your REST API as usual, rendering everything on the client.
If you can, share more details about your case and it will be easier help.
I wouldn't recommend you to bundle the REST API in the browser, as you are limited to using browser-compatible modules in your API, and you won't be able to make any direct database calls.
There's a library that makes it so you can build your APIs in an isomorphic fashion, and re-use it in the client and server without bloating or breaking the bundle. This is what we're currently using in a big single-page application.
It's called Isomorphine, and you can find it here: https://github.com/d-oliveros/isomorphine.
Disclaimer: I'm the author of this library.
Related
I'm experimenting with these 2 technologies to make a secure web app [Currently learning React (60%) and Django (<50%). This is intended to be like a medical database, so doctors and nurses enters their patients' information. They need to login obviously. I wanted to implement React-based UI (And not using the classic method to create views from django), so I've found many tutorials just like this one:
https://www.digitalocean.com/community/tutorials/build-a-to-do-application-using-django-and-react
It basically turns Django into a restAPI, and then the React frontend uses axios to retrieve data from the endpoint. Sounds not bad at all (comparing to the native method of rendering data in a webpage from Django), but the problem is that I have no idea on how to make this secure, you know, Django provides an auth system, which is pretty good and secure, I have to say, but in a project with this structure, the auth needs to be done in React, so there many questions appear:
To start with, is it a good idea to make a project of this structure? (If no, then what could be a good one)
If it's a yes, how can I protect the API so only logged in users can interact with it? (What mechanisms to ensure protection)
Yes, this is absolutely a good idea to separate the client application and the backend server application.
You can access the backend through the rest api basically with any frontend framework/app/script.
Customers are able to extend their own applications with the abilities of your backend service.
You can create multiple different frontends that use the same backend or different parts of the same backend via the rest api (multi-branding, reselling). Or you can just swap the frontend framework every second year to a new one.
It's also easier to create different automations by using the rest api.
And the list goes on.
For django rest api auth I would recommend Token Authentication which is already included in the Django REST Framework and for React use this tutorial for implementing the login and the token handling.
And don't forget to use TLS on your servers, and create API documentation. (Example)
My website will perform CRUD operations and will work with MongoDB and Firebase storage+auth.
What are the reasons / advantages to developing a separate Express server instead of integrating everything in my next.js app?
As far as I have seen, it can all be done in my next.js app, but I still see many projects working with a separate server.
Depends on what your app does and how you are hosting it.
Running Next.Js on a standard server will be of little difference whether you are using nextjs's /api or expressjs.
However if you are hosting on serverless (e.g. Vercel), I would recommend using a separate express server if you have alot of CRUD operations because the warming up of serverless is really bad user experience.
Build and Deployment
Next/JS - If you want to edit something on the backend, and push the changes, it will require you to build the entire JS app, and depending on how big is your app, it can take alot of time (especially if alot of static generated pages).
Express - If you running express separately, you can build and deploy front end and backend separately. It's time saving, and you can also better organise your codes frontend/backend.
Choice of deployment
I have a choice to take advantage of Vercel to host my frontend, with static generated pages and some server side generated pages (automatic scaling, caching, CDN etc), and host my backend with a separate cluster of servers.
PS: I moved from single Next.JS app to NextJs+Express
I can think of a few things why they would have a different server from the one NextJS provides:
Familiarity with Express, Koa, etc. All next-connect helps with this
There is an already existing API in PHP, Express, Flask, etc.
It is literally based on what you would want to do, the extra interactions with MongoDB & Firebase would be same on both the technologies, unless you want to isolate respective things separately, I don't see any harm in doing everything together on next.
Given that the idea of using next.js, as per my understanding would be to utilise server side rendering.
I've been using Next.js with Typescript for quite a while now and I, as of now, have found one reason not to include express.js in my project. And the reason is Vercel.
Since I use Vercel for continuous deployment of my projects, and Vercel Not supporting any custom server as of there Docs here, I refrain from using Express or any other custom servers.
I didn't face any problem performing CRUD operations with MongoDB, can't say about firebase.
On Next.js Docs, I found these points to be considered:
A custom server can not be deployed on Vercel, the platform Next.js was made for.
A custom server will remove important performance optimizations, like serverless functions and Automatic Static Optimization.
But at the end of the day it very personal opinion weather to use a custom server or not. It might depend on a very specific use case you might be looking for.
Personally, I try to keep it to just NextJS, but if I have to manage real-time data with Socket.io, I get a separate server because other than WebSockets, serverless functions can do everything else.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.
I am trying to develop a web application that can communicate with another web application. App1 is an app developed using Angular.js and Struts2. This apps sole purpose is to perform search queries on several databases and returning the information about the products for the user to view. App2, the current app I am developing, will be developed using Angular.js and Flask/Python. This app will be responsible for storing the products the user selects in a shopping cart and allowing the user to make a purchase.
I am stuck as to how to get the two applications to communicate(passing login information, selected items ids, etc.) with eachother.
I have tried passing information via a url redirect (http://www.example.com/?myVar=someData&...) but Angular is giving me a lot of trouble to try and get around that. Even if I can get this to work, I think it would be insecure as data the user shouldn't know will be exposed in the url.
My second thought would be to somehow access the session data from App1 in App2 but that could also lead to security issues.
My final thought would be to some how make a call to App1 that returns a json object that can be parsed in App2 but I am not entirely sure how to pass that information along.
How can I get the two applications to communicate with each other?
Thanks for your help
In my opinion this isn't really within the scope of AngularJS. However, I believe that the best, most accepted practice for communication between web applications in this day and age is RESTful Web Services.
It's not a small topic, but once you get the concept behind it you can use it in any programming language that supports web applications (Java which I'm assuming you're using because of struts has multiple REST libraries, I prefer Jersey but that's just me).
It's also an amazing way to use your Angular front end to talk with its own back end. The entire Angular $resource framework is built around the idea of using RESTful services.
Check out this link on Wikipedia for a brief synopsis of what makes a service RESTful: http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services
Now, that applies to most of what you asked. As far as login information is concerned, that's going to depend on your security implementation. A lot of times you can put information like that in the header of a web services request, and only accept requests that come from trusted servers, etc. but there's a good bit of stuff to understand there. It's an entirely separate topic.
Hopefully this helps you get started. Let me know if you'd like more information or pointers.
In this link: http://www.sencha.com/blog/spotlight-ext-js-customers/
Please scroll to the section :Why We Chose Ext JS
There is this line :
By using Ext JS, we lowered the cost
of developing a Web services API.
But I do not really get the explanation. How cost of developing a Web services API can be lowered by a client side framework?
I don't think the explanation conveys what the author intended. I think they were enthusiastic about ExtJs's AJAX APIs, which are easy to work with and can be called using a number of GUI components (which they mention).
The AJAX and component APIs do not create a server-side Web service API for you though, which their testimonial leads you to believe by saying:
This gives us the benefit of exposing
these same AJAX (JSON) calls, as a
Web services API, to our customers...
By using Ext JS, we lowered the cost
of developing a Web services API.
Well not quite, ExtJs doesn't create a Web Services API for you; it creates a method of interacting with your custom REST (or whatever) API. Although maybe they meant that since ExtJs defines how the client should interact with the server, via their numerous components, their server-side services were easier to create. For instance, ExtJs makes it easy to work with REST webservices, and it defines expectations in callbacks, etc. So in ExtJs providing the client solution, it was easier to devise a server solution (the webservices API) given half of a contract.